Add support for resumability and redelivery to Streamable HTTP transport

[halter73]

The MCP Streamable HTTP transport spec has a section on "Resumability and Redelivery" that "MAY" be supported by the server and "SHOULD" be supported by the client. We currently support it in neither case, although client support seems the easier of the two since we wouldn't have to worry about how to store messages and for how long.

Resumability and Redelivery

To support resuming broken connections, and redelivering messages that might otherwise be
lost:

1. Servers MAY attach an id field to their SSE events, as described in the
   SSE standard.
   • If present, the ID MUST be globally unique across all streams within that
     session—or all streams with that specific client, if session
     management is not in use.
2. If the client wishes to resume after a broken connection, it SHOULD issue an HTTP
   GET to the MCP endpoint, and include the
   Last-Event-ID
   header to indicate the last event ID it received.
   • The server MAY use this header to replay messages that would have been sent
     after the last event ID, on the stream that was disconnected, and to resume the
     stream from that point.
   • The server MUST NOT replay messages that would have been delivered on a
     different stream.

In other words, these event IDs should be assigned by servers on a per-stream basis, to
act as a cursor within that particular stream.

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#resumability-and-redelivery

As part of this work, we should reevaluate whether we are cancelling things like tool call operations when the underlying Streamable HTTP POST request is aborted in cases where resumability/redelivery has not been enabled.