feat: WebRTC reuse QUIC conn

[MarcoPolo]

This lets users listen on the same port for WebRTC and QUIC. Kubo folks asked for this as it would be very beneficial to their deployment.

One open question for me is:

• Do we need to make sure this works well with the Observed Address Manager? I think it should just work, but we should double check. Ideally we should know our public webrtc-direct address if we've discovered our public quic address when they use the same port.

[sukunrt]

Do we need to make sure this works well with the Observed Address Manager? I think it should just work, but we should double check. Ideally we should know our public webrtc-direct address if we've discovered our public quic address when they use the same port.

We should infer the address from the quic address like we do for webtransport. It'll work seamlessly once we have the same logic as inferWebtransportAddrsFromQuic

This is more useful for webrtc than for other transports as a server will never dial /webrtc-direct. It will almost always prefer quic or webtransport or tcp. With this PR, we can infer our publicly visible address from our quic address.

[MarcoPolo]

Discussed out of band about changes to make this order agnostic with the QUIC transport, since, as it is implemented in this PR, the QUIC listener starts first. Sukun and I agreed the existing logic is good enough. Which is to sort the listeners and start the QUIC listener first (if there is one). Summary of the points we discussed:

• To reuse the same port, WebRTC has to go through a QUIC transport.
• It doesn't make sense to always instantiate a QUIC transport when setting up a WebRTC listener.
  • It makes WebRTC unnecessarily depend on a QUIC transport being present.
  • Can lead to hard to debug issues. And cause surprising behavior.
• It's much easier to depend on a QUIC transport that has already been started from a prior QUIC listener.
• Sorting the listeners before starting is relatively easy and straightforward.

[lidel]

Thank you for pushing this forward, reusing same port has big impact for DX/UX, allowing us faster rollout with less hiccups.

Took it for a spin in ipfs/kubo#10463 and fx seems to have issue with libp2pwebrtc.ListenUDPFn.

To reproduce, rebase this PR on top of #2887, to ensure WebRTC Direct is enabled by default, then run go test ./...: fx errors with missing type: libp2pwebrtc.ListenUDPFn (same error as in https://github.com/ipfs/kubo/pull/10463/files#r1697532128).

[MarcoPolo]

We should infer the address from the quic address like we do for webtransport. It'll work seamlessly once we have the same logic as inferWebtransportAddrsFromQuic

I don't think we actually need this anymore. I've made a PR to remove that function here #2892.

[MarcoPolo]

Took it for a spin in ipfs/kubo#10463 and fx seems to have issue with libp2pwebrtc.ListenUDPFn.

That was my mistake sorry. I think it was complaining that it couldn't create the WebRTC transport for the AutoNAT host because I didn't provide it to it (only for the basic host).

[sukunrt]

LGTM!
Thanks @MarcoPolo 🎉

Out of date