Server-side WebSocket code is vulnerable to a targeted DoS attack

[davidmkershaw]

See: #40

My architectural recommendation would be to move the queue to the client side. This eliminates the attack vector where a malicious user could open a connection and send messages to fill up the queue, thus running the server out of memory. I do see that we've limited the max number of messages to 100, but an attacker could figure out that number based on when the termination happens, so it doesn't necessarily mitigate an attack (the attacker simply opens multiple connections to fill up the server's memory). Conversely, that server-side queue limit could cause UX issues for a legitimate user who is experiencing latency issues during the auth process. If the queue were moved client-side it would not only help with auth, but also if the connection goes offline for any other reason. (Related to stagger-offline-ui-changes)