feat: Add Transport::box_multiplexed

[elenaf9]

Description

Transports like QUIC or WebRTC, that natively multiplex their connections, currently require some extra mapping so that they can be boxed into the Boxed<(PeerId, StreamMuxerBox)> type required by the swarm.

This PR adds a box_multiplexed convenience function to the Transport trait for boxing multiplexed transports.
Such a function already existed for the Multiplexed type that is constructed when a non-multiplexed transport is upgrade with a muxer (e.g. when using tcp+yamux). box_multiplexed is essentially the same, with some minor changes to also allow boxing OrTransports (when both inner transports are multiplexed).

Notes

Opening as a draft to hear what folks think about it.
I know there have been discussions (#2829, #3179) in general about finding better abstractions for transports and the interface for using them in libp2p-swarm.
The new function won't solve this, but rather is an intermediary solution until we agree on a new API. Given that designing and implementing such a new API may take some time, I think its worth having this function to ease the usage of transports like QUIC and WebRTC in the meantime.

Links to any relevant issues

• Unable to use QUIC Transport with SwarmBuilder #3179

Open Questions

If we decide to add this function, I would deprecate Multiplexed::boxed in favor of Transport::box_multiplexed in a follow up PR. Any objections?

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[thomaseizinger]

I am planning to move the Transport trait around, see #3072 (comment) which we could take into account as part of touching this code already (i.e. deprecating something). Not a blocker though, just mentioning it for reference!

[mxinden]

Very much in favor of this change.

If I read @thomaseizinger comment correctly, he doesn't mind proceeding here.

Can you add a changelog entry?

[mxinden]

If we decide to add this function, I would deprecate Multiplexed::boxed in favor of Transport::box_multiplexed in a follow up PR. Any objections?

I would include it in this pull request as one is the reason for the other. Not a strong opinion.

[thomaseizinger]

If I read @thomaseizinger comment correctly, he doesn't mind proceeding here.

Happy to if you consider it urgent. It doesn't move in the direction I'd want to because it adds another function to Transport when we actually want to get rid of them.

An alternative solution would be to create a TransportExt trait in libp2p-swarm and add this function there. Then we can move the others over in subsequent PRs.

That would avoid deprecating something down the line that we only introduced recently.

[mergify]

This pull request has merge conflicts. Could you please resolve them @elenaf9? 🙏

[mxinden]

If I read @thomaseizinger comment correctly, he doesn't mind proceeding here.

Happy to if you consider it urgent. It doesn't move in the direction I'd want to because it adds another function to Transport when we actually want to get rid of them.

I don't consider this urgent. What would be your preference? I am assuming we could not define this next to StreamMuxer, i.e. Rust would not allow us to have an impl Transport in libp2p-core if Transport no longer lives in libp2p-core?!

[elenaf9]

An alternative solution would be to create a TransportExt trait in libp2p-swarm and add this function there. Then we can move the others over in subsequent PRs

Introducing a TransportExt trait in libp2p-swarm sounds good to me. If I understand it correctly, the new trait would for now only have the box_multiplexed method until we move the rest over? And should we then also directly change Swarm::with_*executor to accept a generic impl TransportExt?
Edit: Actually, the latter wouldn't work if we also move other methods into TransportExt since we'd then have to trait bound based on TransportExt::box_multiplexed, rather than the whole trait.
Do you feel strongly about removing the other methods from Transport? Imo they are quite generic and not swarm-specific.

[thomaseizinger]

Closed because stale.