Add system/disconnected event

[geekingfrog]

While working on the matchmaking I noticed this event was missing.
It's not strictly necessary for now but it's better to have clean disconnection.

[p2004a]

Note that WebSockets return the code and details in Close frame which is basically the same as this message https://www.rfc-editor.org/rfc/rfc6455.html#section-5.5.1, for example: https://github.com/beyond-all-reason/recoil-autohost/blob/b9cc24e49fbefa2a73f9fbed6dd8dc82f7e236d5/src/tachyonServer.fake.ts#L67

[geekingfrog]

Do we want to carry some json message in the close frame then?

[p2004a]

Hmm, I wouldn't put JSON message there, do you think we would want to? At the moment the code + reason matches more of less 1:1 to our reason + details, and seems to be exactly the same use case.

[geekingfrog]

I thought the code 1002 was meant to indicate a websocket protocol error, not an application error. Do you think we should use 1008 for everything application related and put a simple message only?
For now I think that's probably good enough. One thing I have in mind may be an event to ask for reconnection, but that would make sense when going multi node, so clearly not immediately.

[p2004a]

Yes, I also think 1002 is about lower WebSocket protocol error. I'm returning 1008 when I fail to parse tachyon message.

When the server is restarting that would be 1012 I believe. Overall I would expect the client to be able to reconnect always, not when server tells it to. If we want client to retry with delay there is 1013, or we can add our own in 4000-4999 range.

Anyway, I'm not sure, on one side having it all in json layer is nice, on the other side, client/server must handle the WebSocket error codes anyway and adding it inside tachyon protocol is having the "reason of disconnect" in 2 separate places. But, we already have precedent for using the WebSocket facilities in the protocol: e.g. using subprotocol for version negotiation, passing access token as part of the initial connection request etc, so it's not weird imho to also depend on standard websocket codes for disconnection.

[geekingfrog]

Won't do it this way, instead see: #39