Undeliverable messages in StreamableServerTransport when there are no connected streams.

[jba]

For a brief period of time, a StreamableServerTransport has no streams. Notifications delivered during this gap fall on the floor.

Here is what happens when a client connects to a server using a streamable transport:

1. Client sends an initialize request.
2. Server creates a session.
3. The request completes, ending the POST stream.
4. Client sends a GET to create the standalone stream.

Between 3 and 4, the session exists (is on the Server.sessions slice) but has no streams. Sending messages to the session will fail.

Our tests have never observed this because they always create a server before clients connect, and the change notifications from AddTool and the like happen synchronously, when there are no sessions.

But when change notifications are delayed, as in #671, they may fall into the gap, causing an error to display (although processing is not otherwise affected).

[findleyr]

@jba the question is whether we return an error to the server (indicating that the message was not delivered), or buffer the message. Since clients don't have to start the standalone stream (it is optional), the message may never be delivered.

See also #633, where a user is reporting problems that our Client.Connect blocks on establishing the standalone stream. I made that change specifically to ensure that by the time Client.Connect returns, the client can be assured that it is receiving asynchronous server messages.

I'm not sure what's right, though we should research other SDKs. Fundamentally, the streamable transport is not a bidirectional stream, and so we have to make decisions about message delivery semantics.

[findleyr]

BTW, there's another bug / gap, which I think is also present in the typescript SDK.

IIRC, this is how it works now:

1. If there's no stream, we fail to deliver and return an error (arguably correct)
2. If there is a stream, but no associated HTTP connection and no event store, we fail to deliver (arguably correct)
3. If there is a stream, but no associated HTTP connection and there IS an event store, we consider the message delivered.

There's a minor bug in (3): if we've never delivered a Last-Event-ID to the client, there's absolutely no way for them to replay the stream, and we should consider the stream dead.