Auto reconnect server side

[aasoni]

Description of Changes

Auto-Reconnect: Connection replacement and batch subscribe

Adds the two server-side changes needed for SDK auto-reconnect (proposal 0037).

Connection replacement: a client which reconnects can now send a stable, client-generated session_id query parameter. Each connection still gets its own ConnectionId and its own lifecycle events. The session id only identifies which earlier connection a new one supersedes. When a connection claims a session held by a live connection of the same identity, that connection's actor is stopped and its module-side disconnect lifecycle is awaited before the new connection's client_connected, so a module never observes two live connections for one session, nor the old connection's client_disconnected after the new client_connected.

Batch subscribe: SubscribeBatch and SubscribeBatchApplied register multiple query sets under one subscription-manager lock and evaluate them at a single transaction snapshot. No transaction update can interleave with the responses, so a reconnecting client can replay its subscriptions and reconcile its cache against a consistent snapshot. Per-set errors are reported in the response and the remaining sets still apply.

API and ABI breaking changes

No API breaking change. New V3 websocket protocol message. New clients will not be able to send this to old servers.

Expected complexity level and risk

3 - Primarily because of the changes in module_subscription_actor.rs

Testing

• Smoketests to test superseded connections

[aasoni]

The riskiest changes are probably in module_subscription_actor and are the following:

1. Refactor compile_queries into two functions, hash_queries and compile_hashed_queries
2. Additionally, compile_hashed_queries can optionally take a tx lock so that batched subscriptions can compile and apply all queries under the same lock

This allows batched subscriptions to hash queries outside of the tx lock and then compile them all under the same lock.
Additionally batched subscriptinos will apply under this same lock.
This is the most correct thing to do, however maybe performance wise not the best, I am not sure. We could alternatively acquire and drop a tx lock for each query set compilation separately. However the behavior for a subscription batch of 10 sets each with 5 queries is no worse then for a single set with 50 queries which is why ultimately the change felt fine to me.