feat(webrtc): support webrtc-direct v2

[lidel]

Problem

/webrtc-direct lets a browser dial a public libp2p server with no signalling and no CA-signed cert. That path works by "munging" the local SDP so the server can predict the browser's ICE credentials, and Chrome is taking that ability away (the WebRTC-NoSdpMangleUfrag field trial). Once it reaches stable, browsers can no longer open /webrtc-direct connections to a go-libp2p server, which is the whole reason the transport exists.

I documented it in libp2p/specs#672 (comment)

Fix

v2 spec avoids "munging" and is proposed at:

• docs: webrtc-direct-v2 specs#715

This PR implements it while maintaining backward-compatibility with v1 clients too

Details

• the listener accepts v1 and v2 dialers on one port, picking the flow from the ICE username fragment prefix and rejecting versions it doesn't know;
• v2 carries the browser's own ICE password in the server ufrag, so the server recovers it from the STUN USERNAME with no signalling;
• parsed username fragments are validated (charset and length) before they reach SDP;
• opt-in WithDialerVersion("v2") lets a go node dial v2; v1 stays the default for now. can be flipped in future PR, but also does not matter, GO will not do the dials, JS will (feat: webrtc-direct-v2 js-libp2p#3480), so this is just for formal parity and testing

Testing

This keeps browser-to-server connectivity alive once Chrome flips the trial; verified end to end against a real Chrome (v2, munging off) and js-libp2p both ways.

Details: #3499 (comment)

References

• This PR is GO (Server) part of WebRTC-Direct transport at risk due to Chrome changes (ICE credential munging): alignment and next steps #3499
• The v2 spec: docs: webrtc-direct-v2 specs#715
• JS implementation : feat: webrtc-direct-v2 js-libp2p#3480
  • In practice, this will be THE majority of browser clients that do the v2 dials to Kubo

[sukunrt]

Is this tested via the interop tester?

[lidel]

@sukunrt Not via the interop tester yet. It dials webrtc-direct with the default v1 dialer, so the v2 path isn't exercised there.

I did verify v2 manually end to end against real Chrome (munging off) and js-libp2p both ways: #3499 (comment) (see specific commits listed there)

So iiuc once JS ships dialling v2 (libp2p/js-libp2p#3480) we'll have browser-to-go v2 running as part of CI interop in libp2p/test-plans.

[sukunrt]

Can you add an integration test here?
https://github.com/libp2p/go-libp2p/blob/master/p2p/test/transport/transport_test.go#L342

I think you just need to enable the V2Dialer option.

[sukunrt]

It dials webrtc-direct with the default v1 dialer, so the v2 path isn't exercised there.

Can we enable go v2 dialer to go server meanwhile and add the js dialer when it's merged?

[lidel]

Thanks for pointer @sukunrt, added in 53e9c5a. The transport integration tests now run a WebRTC-v2 case with WithDialerVersion(2), exercising go's v2 dialer against a go server across the full battery (ping, streams, resets, deadlines, rcmgr). I pinned the existing case to v1 too, so both flows are explicit.

It's go dialer to go server, so self-consistency rather than cross-implementation interop. iiuc the JS dialer side lands in libp2p/test-plans once libp2p/js-libp2p#3480 merges, so this PR can be merged without blocking?