Enhancement: remove the get_peer and set_peer method in `Service` trait.

[4t145]

1. When I wrote those two method, there's no good way to access peer in handler methods.
2. And now we can get peer through request context. Which makes those two method looks redundant.
3. I believe there are not many users even know these two method, let alone are using them.

@jokemanfire What's your opinion?

[appyhdu]

Maybe this is not a good idea, because when implementing sampling or tool changes, the service_provider cannot be directly used to let the underlying layer directly host the created objects. After deletion, the RunningService needs to be managed by oneself.

Not even the mcp macro can be used.

[4t145]

@appyhdu We do need to make sure user can get Peer when handling notification. So maybe there need to be a notification context?

[Pluto-Y]

Consider a scenario where a server acts as a resource host（like cos）, with the MCP as a subsystem. When the resource list changes, it is expected to notify the client interface of the changes via a list_changed notification. However, since this does not occur within any request/notification handler function at the moment, the corresponding context information cannot be obtained.

The current solution involves storing the corresponding peer in the initialize handler of the ServerHandler, which is later used to send list_changed notifications.

[4t145]

@Pluto-Y Totally understand this. I prefer providing a context for notification handlers. I will add this feature after #228.