Respect Section 7.1.1 of the RFC6455.

Quoting the RFC, 7.1.1 Close the WebSocket Connection:

   > To _Close the WebSocket Connection_, an endpoint closes the
   > underlying TCP connection. An endpoint SHOULD use a method that
   > cleanly closes the TCP connection, as well as the TLS session, if
   > applicable, discarding any trailing bytes that may have been
   > received. An endpoint MAY close the connection via any means
   > available when necessary, such as when under attack.
   >
   > The underlying TCP connection, in most normal cases, SHOULD be
   > closed first by the server, so that it holds the TIME_WAIT state
   > and not the client (as this would prevent it from re-opening the
   > connection for 2 maximum segment lifetimes (2MSL), while there is
   > no corresponding server impact as a TIME_WAIT connection is
   > immediately reopened upon a new SYN with a higher seq number). In
   > abnormal cases (such as not having received a TCP Close from the
   > server after a reasonable amount of time) a client MAY initiate the
   > TCP Close. As such, when a server is instructed to _Close the
   > WebSocket Connection_ it SHOULD initiate a TCP Close immediately,
   > and when a client is instructed to do the same, it SHOULD wait for
   > a TCP Close from the server.

Consequently, now, the client starts the disconnection, mute the socket,
wait for a reply from the server and then disconnect the socket. We have
a timeout defined by 2 * MSL. We have choosen the MSL value of FreeBSD.
Since some server (such as tomcat) emit a log when connection are not
properly closed, this PR will avoid useless logs