Keep same connection ID when reconnecting

We spoke about allowing Connections to keep their existing ID when reconnecting so we can have a persistent src across all ops belonging to an interruptible "session" on a flaky connection.

We'd suggested allowing the Connection to optionally propose an ID to the Agent (rather than just always being assigned one). However, if I understand this all correctly, then the connection flow (as it stands) looks something like:

• Open a socket between client and server boxes
• In parallel:
  • Construct a client-side Connection object with this socket
  • Construct a server-side Agent object with this socket
• Connection sets it state to 'connecting' until it receives a message from the Agent
• Agent sends an 'init' message, with the client ID
• Connection receives the message, sets its ID and sets its state to 'connected'

If the above is correct (please correct me if I'm wrong), then the only approach I can think of which would allow the Connection to propose an ID — without breaking existing behaviour — would be: propose the ID on creation of the socket, outside of ShareDB (eg as a query string on a websocket URL). This feels like it puts too much onus onto the library consumer, so probably not an acceptable solution?

Other approaches would be breaking changes to the connection handshake:

• Make the Agent wait for a message from the Connection before sending 'init': breaks when old clients connect to new servers, because the Agent is waiting for a message it will never receive
• Have the Connection counter-propose its assigned ID: breaks when new clients connect to old servers, because the Agent doesn't know what to do with the new message, and the Connection will wait forever for a response

Of course, we could hide this behaviour behind a feature flag if we want to stay on v1, but any changes to the handshake feel like they really belong to this bigger package of work?

Or perhaps the counter-proposal solution could work by checking the Agent's protocol version? If it's 1, then we know we can't counter-propose, but if it's 2, then we can? (Or some other semver thing like 1.1.0)

Start by reading the Connection/Agent handshake implementation and the broader work in issue #337; the issue provides no file or test entry point. This is done only when a backward-compatible approach for preserving the connection ID is agreed and its compatibility behavior is verified.