feat: add ignorable JSON-RPC methods support for both client and server

[tzolov]

• Add ignorableJsonRpcMethods support to McpClientSession and McpServerSession
• Implement request and notification filtering for specified methods
• Add default ignorable methods: notifications/cancelled, notifications/stderr
• Extend both client and server builders with ignorableJsonRpcMethods() methods
• Support both List and varargs configurations
• Add comprehensive test coverage for client and server-side functionality
• Maintain full backward compatibility with deprecated constructors
• Log ignored methods as DEBUG for debugging visibility

This feature allows both MCP clients and servers to gracefully handle unknown or unwanted JSON-RPC methods without generating errors, improving compatibility with various implementations and reducing log noise.

Resolves #416, #377

Related to #130 It provides a workaround until the notification/cancelled is supposed.

Motivation and Context

This change addresses the need for more robust MCP communication by allowing clients and servers to ignore specific JSON-RPC methods rather than generating error responses. This is particularly useful for:

• Handling notifications like "notifications/cancelled" and "notifications/stderr" that may not be relevant to all implementations
• Providing backward compatibility when new methods are introduced
• Reducing noise in logs from unknown method calls
• Allowing more flexible MCP implementations that can gracefully handle method calls they don't support

How Has This Been Tested?

• Added comprehensive unit tests for both sync and async client builders (AbstractMcpAsyncClientTests, AbstractMcpSyncClientTests)
• Added unit tests for both sync and async server builders (AbstractMcpAsyncServerTests, AbstractMcpSyncServerTests)
• Added session-level tests for both client and server sessions (McpClientSessionTests, McpServerSessionTests)

Breaking Changes

This is a non-breaking change. All existing APIs remain unchanged, and the new functionality is opt-in through builder methods. Default behavior is preserved with a predefined list of commonly ignorable methods.

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

Implementation Details:

• Added Utils.DEFAULT_IGNORABLE_JSON_RPC_METHODS constant with default methods: "notifications/cancelled" and "notifications/stderr"

[chemicL]

gracefully handle unknown or unwanted JSON-RPC methods

I think in the current form this PR does not address this. The mechanism introduced requires the JSON-RPC methods to be known and actually wanted.

Have you considered an alternative mechanism, which I'd call "ignoreByDefault" accompanied by a mechanism for "disallowed methods", which would consist of a boolean flag that if true (and the default would be true) accepts notifications for unknown methods and for requests...

Well, I have a bit of an issue with requests though. For example, a server that accepts a request and returns no body makes the client wait forever? Or until timeout? What is the expected next step for the client? Depending on the transport it might consider the server as misbehaving. From the perspective of a client author, I'd expect to be told I'm sending something the server will not provide a response for.

So this mechanism probably should only work for notifications.

The other part of my proposal is about the disallowed methods, for which the user might explicitly specify that an error should be reported against the other party.

[tzolov]

I agree that we can not silence the request!
That undermines the purpose of this change. I'm closing this PR and related issue.