DummyTransport when using other transport

Summary

When building swarm with .with_other_transport() in 0.53.1 I notice a bunch of these in logs:

2023-11-17T06:49:48.958626Z DEBUG Swarm::poll: libp2p_core::transport::choice: Failed to dial address using libp2p_core::transport::dummy::DummyTransport<(libp2p_identity::peer_id::PeerId, libp2p_core::muxing::boxed::StreamMuxerBox)> address=/ip4/38.242.232.164/udp/30433/quic-v1/p2p/12D3KooWNq4jwEogz2mwEP1EzjCNFngc9GWk5QtNpqxrdxfHLyrm
2023-11-17T06:49:48.958675Z DEBUG Swarm::poll: libp2p_core::transport::choice: Failed to dial address using libp2p_core::transport::dummy::DummyTransport<(libp2p_identity::peer_id::PeerId, libp2p_core::muxing::boxed::StreamMuxerBox)> address=/ip4/38.242.232.164/udp/20681/quic-v1/p2p/12D3KooWNq4jwEogz2mwEP1EzjCNFngc9GWk5QtNpqxrdxfHLyrm
2023-11-17T06:49:48.958706Z DEBUG Swarm::poll: libp2p_core::transport::choice: Failed to dial address using libp2p_core::transport::dummy::DummyTransport<(libp2p_identity::peer_id::PeerId, libp2p_core::muxing::boxed::StreamMuxerBox)> address=/ip4/38.242.232.164/udp/49969/quic-v1/p2p/12D3KooWNq4jwEogz2mwEP1EzjCNFngc9GWk5QtNpqxrdxfHLyrm

Expected behavior

I do not expect to see dummy transport in logs unless configured

Actual behavior

Dummy transport is still used due to the following:
https://github.com/libp2p/rust-libp2p/blob/2ecc7cf1253e5a884d093fc51b4ba35c45a57842/libp2p/src/builder/phase/tcp.rs#L181-L183
https://github.com/libp2p/rust-libp2p/blob/2ecc7cf1253e5a884d093fc51b4ba35c45a57842/libp2p/src/builder/phase/tcp.rs#L102-L112
https://github.com/libp2p/rust-libp2p/blob/441c242555b13bf8144df72c1f3a64e049c139d3/libp2p/src/builder/phase/quic.rs#L64-L72
https://github.com/libp2p/rust-libp2p/blob/441c242555b13bf8144df72c1f3a64e049c139d3/libp2p/src/builder/phase/other_transport.rs#L25-L58

So we're going from Quic(Tcp) to Quic(Dummy) to Dummy to Dummy(TransportUserProvided).

Relevant log output

No response

Possible Solution

Solution here would be to somehow replace the transport with a custom one rather than chaining it with Dummy transport.

Generally I don't really understand why would you un-wrap TCP and UDP (that user didn't ask to do) and chain dummy with custom transport instead of simply replacing the transport. A bit strange implementation to be honest.

Version

0.53.1

Would you like to work on fixing this bug ?

Maybe

Start by reviewing the linked builder phases in libp2p/src/builder/phase/tcp.rs, quic.rs, and other_transport.rs, focusing on how transports are chained when with_other_transport() is used. Trace the construction from Quic(Tcp) through Dummy to the user-provided transport, then verify that an unconfigured DummyTransport no longer produces these dial logs while the configured transport still works.