feat: Extract McpAsyncClient and McpSyncClient as an interface

[He-Pin]

Motivation and Context

Helpful for users who want to have a different implementation but the same interface for better third part integration.
#680

How Has This Been Tested?

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

[He-Pin]

Our current implementation requires significant extensions to McpAsyncClient to implement custom behaviors. However, because some methods are private, we cannot modify them externally, forcing us to copy the code. This necessitates using different class names, resulting in a poor user experience for our second-party applications and third-party integrations. Therefore, we aim to transform McpAsyncClient and McpSyncClient into a single interface, allowing us to return our custom implementation when needed. This way, users in the community with similar requirements can also return the same interface with different implementations.

This is a basic source code compatibility change.

[Randgalt]

Can you document what significant extensions you've had to make to McpAsyncClient? We've been able to use this library with significant internal changes without the need for this.

[He-Pin]

Hello, I need to implement enterprise-level MCP task support in my work. We need to return our own extended MCP client implementation, which is more complex internally. I think adjusting it to an interface would be basically source code compatible, right?

@Randgalt

[Randgalt]

I have just implemented enterprise-level MCP task support in our code base and I didn't need to change anything in this library. ¯\(ツ)/¯. See here: airlift/airlift#1650

[He-Pin]

Thanks for sharing. Does your system support asynchronous notifications? For example, can you still receive notifications after your McP client restarts, or do you require the client user to save the context themselves and then fetch the latest task status after startup? Also, without modifying the client, how do you dynamically add listTasks, etc., in the current implementation? We can certainly achieve this by adding a wrapper and then making some modifications using varhandles.

[Randgalt]

Does your system support asynchronous notifications? For example, can you still receive notifications after your McP client restarts, or do you require the client user to save the context themselves and then fetch the latest task status after startup

The client side hasn't been addressed yet. We're less concerned with clients as clients will use whatever lib they might want. As I read the spec, however, a client that wants to survive restarts, etc. will need a backing store of some kind. This will require some thought. I think injecting a backing store of some kind to McpAsyncClient would be required. This is why I commented on this. I think this kind of support should either be built into the library or an alternate client be provided. This PR seems premature to me.