Proper handling of close frames

[sanmiguel]

The way we handle close frames is a little lacking wrt RFC-compliance. There are a couple of issues already open around this behaviour ( e.g. #16 & #48 ) and tangentially PR #58.

The following extracts from the RFC (section 5.5.1) are where I think we need to better define and codify behaviour:

[re: close frame payload contents]
  This data is not necessarily human readable but
   may be useful for debugging or passing information relevant to the
   script that opened the connection.  As the data is not guaranteed to
   be human readable, clients MUST NOT show it to end users.

---

   The application MUST NOT send any more data frames after sending a
   Close frame.

In practice, we almost certainly end up complying with this, but it's not explicitly codified.

---

   If an endpoint receives a Close frame and did not previously send a
   Close frame, the endpoint MUST send a Close frame in response.  (When
   sending a Close frame in response, the endpoint typically echos the
   status code it received.)  It SHOULD do so as soon as practical.

Simplest way to comply with this is to immediately send that response Close frame and then...

   After both sending and receiving a Close message, an endpoint
   considers the WebSocket connection closed and MUST close the
   underlying TCP connection.  The server MUST close the underlying TCP
   connection immediately; the client SHOULD wait for the server to
   close the connection but MAY close the connection at any time after
   sending and receiving a Close message, e.g., if it has not received a
   TCP Close from the server in a reasonable time period.

So we should wait for tcp_closed but we MAY actively close it first... Before dropping into disconnected.
If we wait for tcp_closed (i.e. server has closed the socket) we must ensure we block any attempt to send more data.

---

   If a client and server both send a Close message at the same time,
   both endpoints will have sent and received a Close message and should
   consider the WebSocket connection closed and close the underlying TCP
   connection.

Note that this implies that, when we are closing the connection and have sent a Close message, we should NOT expect the incoming Close message to match ours in any way.