quic: index hole-punches by remote address and `PeerId`

Description

In https://github.com/libp2p/rust-libp2p/commit/cf3e4c6860d591fb53b40fc95f40ef9a9b6af363, we added hole punching for QUIC. Currently, the map of active hole punches is indexed only by the remote's address.

This presents a problem if multiple peers share a single UDP socket.

To be fully correct, we should index our hole punches by socket address AND expected PeerId. To implement this however, we need to upgrade the connection in the QUIC transport, as the incoming connection is just a Future.

How this upgrade should happen is unclear:

1. Spawning a new task from inside the Transport would create potentially unbounded work where a remote node can spam us with incoming connections.
2. Running the upgrade on the main task would introduce latency to usercode that also drives NetworkBehaviours.
3. Having a single background task remove the parallelism we have for connection upgrades in the Swarm.

One possible solution that we've debated is to move away from upgrading connections in the Swarm and instead change the Transport interface to do this for us. To still have parallelism for those, each Transport implementation would have to do this itself. Additionally, dial and dial_as_listener would no longer be able to return a Future but would have to return a DialId and the established connection as part of its event in poll.

This in turn presents a new problem: We need to be able to cancel in-progress dials to implement something like happy-eyeballs. Currently, we can just drop the returned Future.

Are you planning to do it yourself in a pull request?

No.

Start by reading the QUIC hole-punching implementation and the Transport and Swarm connection-upgrade paths described in the issue. Compare the proposed upgrade designs, including dial cancellation and parallelism, and consider the work complete only when active hole punches are keyed by socket address and expected PeerId without unbounded work or added usercode latency.