feat: dial direct connections for DCUtR instead of reusing the relay

[adust09]

Closes #258. Depends on #266, #267 (merged).

Problem

dial checked the connection pool before looking at the addresses given to it. DCUtR runs while a relayed connection to the same peer exists, so it got that connection back and reported success without emitting a packet. No TCP simultaneous connect is possible that way. Neither side dialled directly, and nothing started the upgrade at all.

specs/relay/DCUtR §5: "Upon receiving the Sync, A immediately dials the address to B. Upon expiry of the timer, B dials the address to A. This will result in a TCP Simultaneous Connect. For the purpose of all protocols run on top of this TCP connection, A is assumed to be the client and B the server."

Change

DialOpts and dialWith mirror the two context values go-libp2p's hole puncher sets together, WithForceDirectDial and WithSimultaneousConnect. dial is the wrapper supplying defaults, so no caller changed.

• doForceDirect skips pool reuse and the backoff check (still records backoff on failure, as go does) and skips dial dedup. Skipping dedup is required: DCUtR dials once per address so all are attempted at the same instant, and swPendingDials shares one result among waiters, which would collapse them to a single address.
• doUpgradeAsClient selects the security and muxer roles. upgradeOutbound/upgradeInbound collapse into upgradeAs, deriving every role from the direction as go's upgrader does (isServer := dir == DirInbound). Without it both ends pick Yamux RoleClient and their stream ids collide.

The reversed connection is Inbound and its resource slot is reserved and released as Inbound. closeConnection releases by connDirection, so the two must agree.

Testing surfaced a second defect: neither the hole punch dial nor the coordination exchange was bounded. A simultaneous connect that fails to collide lands on the peer's ordinary listener, leaving both ends running the responder side and waiting on each other forever. Both are bounded now, with go's defaults of 10s for the dial and 1m for the stream.

isPublicAddr is new in LibP2P.Multiaddr, mirroring go-multiaddr's manet.IsPublicAddr. Nothing equivalent existed. isRelayedAddr moves next to it so the connection pool can use it without depending on the NAT stack.

lookupConn now prefers direct over relayed, keeping the choice in one place as go's bestConnToPeer does, and still returns the relay when it is all there is. On success the relay closes after a 15s grace period, but only if a direct connection is still up.

registerNATHandlers subscribes a notifier on Inbound && isRelayedAddr, the same condition as go's holepuncher.go:281. upgradeRelayedConnection is exported for direct use; it calls identifyPeer itself rather than racing the identify notifier.

Out of scope

Role flip on the final retry, which is go's pre-v0.41 compatibility workaround and not in the spec; revisit under #131. QUIC hole punching (#235). Migrating existing long-lived streams, which the spec says "will have to be recreated".

[seetadev]

@adust09 : Great work on this, Shouki. This is an important fix for making DCUtR perform the direct simultaneous connect rather than accidentally reusing the existing relay.

Appreciate the careful handling of force-direct dialing, deduplication, connection direction/upgrade roles, timeouts, and the direct-vs-relayed connection preference. The alignment with go-libp2p’s behavior and the additional testing around the failure/hang cases make this a solid improvement.

Great to see the relay fallback and grace-period handling preserved as well. Thanks for the thorough implementation and testing here. LGTM, happy to approve and merge.