feat(graphql): backoff for dropped connection after ACK

[stdevi]

Add exponential backoff before reconnecting when an already-established GraphQL WebSocket connection drops, so a connection that keeps dropping right after connection_ack doesn't turn into a tight reconnect loop.

Previously handleConnectionDrop() (pong timeout, failed send, or resubscription failure) reconnected immediately via openSocket(). Each reconnect mints a fresh temporary API key, so a server that drops the socket right after ACK produced a fast key-minting loop. The onclose handler already backed off for connections that never established; this brings the post-ACK drop path in line.

So now we:

• Back off in handleConnectionDrop() using calculateRandomizedExponentialBackoffTime(connectionAttemptsCount) before reconnecting, reusing the same counter as onclose (reset to 0 on GQL_PONG), so a healthy connection that drops starts from the minimum.
• Tear down the old socket (tearDownSocket()) before the backoff sleep, so its onclose can't fire a second, parallel reconnect during the delay. The handlers are nulled before close(), so the asynchronous close event has nothing left to trigger.
• Keep the synchronous DISCONNECTED emit up front, so the dashboard's connection-loss status is unaffected.
• Extract the duplicated teardown block into a shared tearDownSocket() helper used by both createSocketConnection() and handleConnectionDrop().

How to test

• yarn test (new tests in graphql-reconnect-resilience.spec.ts):
  • drop after ACK backs off using the attempt counter and increments it
  • the reconnect is deferred until the backoff delay elapses (not immediate)
  • the old socket is torn down before the sleep so its onclose can't reconnect

Bumps qminder-api to 17.0.5.