Refactor websocket close logic

[lorenzodonini]

• Fixes potential deadlocks and panics, that may occur when closing websockets
• Streamlines websocket close logic for client and server
• Gracefully closes all clients, after calling Stop on the websocket server
• Fixed typos in documentation

[michaelbeaumont]

There's no reason to have different readPump/writePump methods for client and server is there? Or put another way, I think the right abstraction might be "connection" and "server", where a server just manages multiple connections.

[lorenzodonini]

There's no reason to have different readPump/writePump methods for client and server is there? Or put another way, I think the right abstraction might be "connection" and "server", where a server just manages multiple connections.

There are a few subtle differences between the two, like:

• the ping/pong mechanism (which adds an additional timer channel and two code blocks, different on each entity)
• the auto-reconnect mechanism, which is only triggered in the client
• message handling callback
• closing logic and error handling

I could definitely abstract this away with a few function parameters, pass a nil channel to the entity that doesn't send the ping and add a couple more conditions, but I'm afraid it won't read as nicely and look as clean.
I'm willing to give it a try, if you believe it would be worth it, but in general I'm not against code duplication, when two entities actually behave differently.

[lorenzodonini]

I merged this one for now, will tackle your suggestion in a separate MR.