feat: Client transport support connection closed event

[taobaorun]

Motivation and Context

In numerous real-world MCP service invocation cases, we have observed that when Server-Sent Events (SSE) connections are disrupted due to server-side maintenance operations or network instability, clients often fail to promptly detect these disconnection events. This delay in detection can lead to client instances becoming unavailable. There is a critical need for clients to reliably perceive connection status changes, enabling them to perform timely reinitialization actions such as establishing new connections and implementing effective connection monitoring strategies.

How Has This Been Tested?

This functionality has been validated in actual MCP service deployment environments. Testing scenarios included:

• Simulated server maintenance events that intentionally terminated SSE connections

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[taobaorun]

Hey @tzolov @chemicL ,could you please take a look at this PR when you have a moment?

This change addresses an issue where MCP clients can become unresponsive due to undetected SSE connection drops. It ensures clients can reliably detect disconnections to enable timely reconnection and maintain service availability.

[taobaorun]

@Kehrlann Please help review this pr

[Kehrlann]

Hey @taobaorun sorry for the long, long delay. I'm getting back at it. Notable: #610 also introduces a close handler (for a different purpose), it might make sense to look at these two in parallel.

In any case, this has drifted by quite a lot, so if you want to carry forward, you'll have to fix a few conflicts.

A few questions:

• Why do you need to update the handler with a setter, rather than a simple constructor argument?
• Why is the handler a Consumer<Void> rather than Runnable ?

[Kehrlann]

This is a client-side close. You should consider closing the server instead, to simulate the case you were mentioning in the PR description. Same goes for the other transport.