Expose connection id in request-response events

[bastienfaivre]

Description

Hi, while working with the request-response protocol, I realized I cannot access the connection id when processing request-response events.
I would suggest making it part of the behaviour events:

/// The events emitted by a request-response [`Behaviour`].
#[derive(Debug)]
pub enum Event<TRequest, TResponse, TChannelResponse = TResponse> {
    /// An incoming message (request or response).
    Message {
        /// The peer who sent the message.
        peer: PeerId,
        /// The connection used.
        connection_id: ConnectionId,
        /// The incoming message.
        message: Message<TRequest, TResponse, TChannelResponse>,
    },
    /// An outbound request failed.
    OutboundFailure {
        /// The peer to whom the request was sent.
        peer: PeerId,
        /// The connection used.
        connection_id: ConnectionId,
        /// The (local) ID of the failed request.
        request_id: OutboundRequestId,
        /// The error that occurred.
        error: OutboundFailure,
    },
    /// An inbound request failed.
    InboundFailure {
        /// The peer from whom the request was received.
        peer: PeerId,
        /// The connection used.
        connection_id: ConnectionId,
        /// The ID of the failed inbound request.
        request_id: InboundRequestId,
        /// The error that occurred.
        error: InboundFailure,
    },
    /// A response to an inbound request has been sent.
    ///
    /// When this event is received, the response has been flushed on
    /// the underlying transport connection.
    ResponseSent {
        /// The peer to whom the response was sent.
        peer: PeerId,
        /// The connection used.
        connection_id: ConnectionId,
        /// The ID of the inbound request whose response was sent.
        request_id: InboundRequestId,
    },
}

Motivation

Since multiple connections can be made to a given peer, knowing which connection was used for a given request-response shot would be helpful. Indeed, one might need to act based on connection ID when receiving a request or a response.

Current Implementation

The current state of the code keeps the connection id (provided as a parameter in fn on_connection_handler_event(...) for instance) private.

Are you planning to do it yourself in a pull request ?

Yes

[dariusc93]

Hey! Thanks for the suggestion and it does to some degree make sense to track the connection id itself along with the request.

[elenaf9]

Indeed, one might need to act based on connection ID when receiving a request or a response.

Could you give an example/ usage-case for this?

[bastienfaivre]

@elenaf9, in my case, I need to identify or flag the corresponding connection id based on my application's logic, which tracks specific connections (at the connection ID granularity, not the peer ID). Without access to the connection id in the request-response protocol, I cannot distinguish between all open connections to a given peer, preventing me from implementing a simple, deterministic logic.

[elenaf9]

Okay, adding the connection id sounds good. We also already do that e.g. for identify events.

[bastienfaivre]

Thank you. I will implement this and open a PR as soon as it is ready!