Fix reconnection deadlock

[quinchs]

Summary

When the binding idles for 2 ish minutes, the server sends an IDLE_SESSION_TIMEOUT_ERROR error indicating that the binding should disconnect until another query is ready to be run.

The bindings logic would reset the state of the connection and only attempt to reconnect on a query call, the issue lies with the implementation of this logic with Netty. When the client resets the promises for indicating both when the client is connected as well as the ready state (when the binding receives READY_FOR_COMMAND message). The issue lies with the connection ready state, since our code looks like the following psuedo-code:

public CompletionStage<Void> send(Sendable message) {
  return whenConnectionReady()
    .thenCompose(v -> {
      if(!this.isConnected) {
        return reconnect().thenCompose(v -> send0(message));
      }
      return send0(message);
    });
}

we rely on the connection ready event to preform reconnect logic, the reason for this is the following states:

• If we're already starting a connection and queue up the client handshake to be sent, the send method should wait for that connection to succeed or fail before trying to send a message
• If we're already connected this completion state is successful allowing the binding to send the message right away.

During reconnect logic, if the binding detected a disconnect it would call the client connect method, which is responsible for resetting the connection state which includes both promises, the way it would reset the connection promise is by triggering a custom Netty pipeline event that resets the promise:

@Override
public void userEventTriggered(ChannelHandlerContext ctx, @NotNull Object evt) {
  if(evt.equals("RESET")) {
    // resets the promise
  }

  ...
}

The issue was that this pipeline event wasn't triggered synchronously with the connection reset code, so ultimately it would keep the old promise (which has been completed) and follow the reconnect cycle again which is controlled by a lock, causing a deadlock.

This PR fixes that by making the reset promise synchronous within the pipeline by making the callee run the reset instead of the netty pipeline thread.

[quinchs]

cc @petersamokhin this most definitely the issue you we're facing, this should fix it.