Refactor agent method implementations to allow extension and custom methods

[Blackhex]

Description

The 3.5. Method Mapping and Naming Conventions section of the specification defines conventions for JSON-RPC/gRPC/REST methods mapping and defines existence of custom or extensions methods.

Currently, the handlers for the same methods for different transports are implemented on different places taking information from ad-hoc source locations and custom or extension methods are not supported, see JSON-RPC server implementation vs. JSON-RPC client implementation vs. REST implementation. gRPC method handlers does not seem to be implemented either?

Within this task, propose a way how to abstract all information needed to serve and handle requests to agent methods (including custom or extension ones) for all supported transports so adding a new method will be matter of deriving single abstract class and its registration without the necessity of changing transport-specific handlers implementations on multiple places.

NOTE: Command or similar design-pattern can be utilized for this.

NOTE: Adding support for custom or extension methods might involve adding a new method to A2AEndpointRouteBuilderExtensions.cs or adding a new parameter to A2AEndpointRouteBuilderExtensions.MapA2A() that will allow defining the custom methods. Alternatively, similar concept as TaskManager can be introduced to manage custom methods implementations.

Motivation

• Reduce code duplication and improve architecture of the library (open-close principle).
• Enable user-defined custom or extensions methods implemented using the same mechanisms as built-in methods are.

[darrelmiller]

We should always be looking for ways to minimize duplication across the transports, however, it is important to note that there are currently some significant differences between how the transports pass the application data across the wire. Some examples:

• HTTP/gRPC response to stream/message is a different structure
• JSONRPC has support for the metadata parameter on get methods but HTTP does not currently
• HTTP request handling is significantly different than JSONRPC because dispatching can occur before deserializing the request body.

I expect a gRPC implementation would map directly to the HTTP implementation, so there would be some alignment there. I'm a bit skeptical of us being able to align the JSONRPC and HTTP implementations without introducing a fair amount of complexity into the HTTP path.

Perhaps when the A2A specification has been refined to align the transports better it will be more feasible to align the implementation, but I would be cautious about doing any significant work just yet.

[Blackhex]

I agree that alignment could be a little bit challenging considering the decisions that had to be made in the past. On the other hand, Python implementation managed to do that alignment recently by adding multi-transport support by wrapping the old single-transport implementation

Nevertheless, the effort of this ticket should be focused only on unification of the methods handling, not the entire request handling flow, so it should have much narrower scope than what would full multi-transport implementation require.

[rokonec]

I am all for it. Having method handling with higher code reuse will indeed increase code quality. Having unified method handling will allow unified instrumentation, validation and testing.
I think it is worth it.