Multiple WebSockets are created when a content filter blocks WebSocket

[boxmein]

When using the Javascript SDK in a browser, and a content filter that restricts WebSocket traffic is in place on the customer's computer, it is possible that multiple websockets are created.

The following sequence of events must occur:

1. Consumer code calls Qminder.GraphQL.subscribe(...).subscribe(...)
2. The Connection API key is fetched quickly
3. The WebSocket initialization handshake starts and an error occurs (e.g. a HTTP 4xx/5xx reply during the handshake)
4. Another part of consumer code calls Qminder.GraphQL.subscribe(...).subscribe(...) again
5. The Connection API key is fetched quickly
6. The WebSocket initialization handshake starts again
7. The previous sleepMs() timeout introduced in fix: reconnect to socket for all close codes except 1000 #577 is not cancelled, and fires eventually
8. ⚠️ A second WebSocket is created

[boxmein]

This does not appear to have a compounding effect, unlike #587 .

An appropriate fix would be to stop any pending waiting reconnection requests when attempting to connect again.

Prior art:

• Slack Socket Mode SDK uses a state machine that will reliably transition to a CONNECTING state, closing off any pending timeouts.
• graphql-ws manages reconnections separately, decoupling any subscribe() calls and the connection retry loop

[boxmein]

Fixing this was left out of #577 due to #577's importance in providing high WebSocket delivery quality.