Resumption of streamable HTTP session has potential for deadlock

[wreed4]

This stemmed from trying to fix the test_streamablehettp_client_resumption test.
This seems to intermittently fail due to the following behavior (seemingly)...

General layout of the test:

• create a tool called "long_running_with_checkpoints" which we are intending to break our connection with before it finishes (and resume it later).
• register a message handler which is called from shared/session.py::_receive_loop by calling self._handle_incoming which calls the client/session.py version of that function which calls our message handler
• Create a client
• Start the tool
• Wait for it to send the first notification and then disconnect
• THE TOOL WILL CONTINUE RUNNING

then, the intended flow seems to be

• reconnect to the tool
• pick up the remaining notifications it sent us
• profit

However, this only seems to work correctly if the tool has sent another notification before we reconnect to it. If the tool has yet to send another notification, the call to send_request hangs forever.

Originally posted by @wreed4 in #840 (comment)

[davemssavage]

This is probably the underlying cause of #744