Document "Smart Dialing"

libp2p implementations support a wide range of transport protocols (TPC, QUIC, WebSockets, WebTransport, WebRTC (upcoming.)) A libp2p node will have a multiaddr for each transport protocol it supports.
When a libp2p node tries to connect to a peer, it receives the peer's multiaddr list, and selects a multiaddr to dial/connect with.

Currently, this selection is not optimized.
As libp2p implementations support more transports (and as more metadata gets stuffed into multiaddrs), a node's multiaddr list will grow much larger.
Therefore, the go-libp2p implementation is planning to introduce improvements to dialing beginning end of Q4 2022.

• go-libp2p Smart Dialing roadmap project

Done Criteria

• Documentation describing these optimizations exist (to be decided: as its own doc under a new "Advanced Concepts" section, other existing relevant docs link to it)
• https://github.com/libp2p/docs/issues/216
• Document QUIC Blackhole detector (issue to be created)
• Document RTT estimation (issue to be created)

Why Important

Users should know and understand how libp2p decides to select which peer multiaddr to dial, how it picks which addr will result in the most performant & successful connection, and why this matters (conservative optimizations are used to reduce a burden on resources.)