protocols/relay: Reconsider listener streams in `ClientTransport`

[elenaf9]

Description

With #2652 the concept of listeners was removed from the Transport in the sense that having listener streams is not enforced anymore. Instead the transport is responsible for managing its listeners and polling them.

As part of #2652 the relay ClientTransport was adjusted to the trait changes so that now the ClientTransport manages and drives its listener streams. The underlying architecture was not changed and the concept of listeners remains internally. How it currently works is that:

• for each relayed listening address, we create a new Listener stream and drive it for events
• communication from the Behaviour to the ClientTransport (necessary for informing the Listener of the result of a reservation and of incoming relayed connections) is done via a channel from the Handler (of the connection to the relay) to the Listener
• said channel is created in the ClientTransport, then sent via a channel from transport to behaviour, and then passed from behaviour to the handler.

With the transport changes of #2652, we may be able to reduce the complexity here by removing the listener streams.

The client transport must be aware of the different listeners, but it may not need to drive an extra stream for each listener. One idea would be to just have one channel between behaviour and transport for each direction and track the necessary states directly in the ClientTransport and Behaviour. I originally considere to do something like this in #2652, but eventually decided against it because of the reasons described in https://github.com/libp2p/rust-libp2p/pull/2652#discussion_r908166356.

However, I did not look into it in too much detail, and I think it is still worth exploring. Maybe @mxinden you can also give some input here as the original author of the relay_v2 protocol.

[mxinden]

Thanks for documenting this!

Maybe @mxinden you can also give some input here as the original author of the relay_v2 protocol.

I am in favor of the above suggestion. That said, I haven't played through it in detail myself, thus I can't comment whether it will turn out to be fruitful.