feat: WebRTC-Direct support for Node.js

[achingbrain]

Supports listening and dialing WebRTC Direct multiaddrs in Node.js.

Depends on:

• WebRTC-Direct ufrag/STUN username field not prefixed with libp2p+webrtc+v1/ go-libp2p#2827
• Add callback to get unhandled STUN binding requests from mux paullouisageneau/libjuice#248
• feat: add remoteFingerprints method to PeerConnection paullouisageneau/libdatachannel#1206
• feat: pass custom ICE ufrag and pwd as local description init paullouisageneau/libdatachannel#1207
• fix: add types field to package.json murat-dogan/node-datachannel#258
• fix: export DescriptionType enum values murat-dogan/node-datachannel#259
• feat: accept preconfigured PeerConnection as polyfill arg murat-dogan/node-datachannel#260
• feat: support setting ICE ufrag and pwd, disabling fingerprint validation and specifying certificates murat-dogan/node-datachannel#256
• feat: add callback for unhandled STUN requests paullouisageneau/libdatachannel#1211
• feat: support multiple juice_mux_listen callbacks for different ports paullouisageneau/libjuice#292

Closes:

• Tracking Issue - WebRTC direct in Node.js #2581

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[xicilion]

I read the code a bit, in this implementation when Peer B listens, it first listens for incoming stun packets using dgram, extracts the ufrag, and then establishes a connection with Peer A from another port. This works fine in a direct network connection.
But if Peer A is behind NAT, this type of connection will fail because the NAT detects incoming packets from another port, which was not accessed from inside before.

[achingbrain]

I haven't got to the point of testing NAT traversal yet, still a lot of PRs to land in the deps.

I was wondering if each RTCPeerConnection could negotiate it's own NAT traversal via STUN/TURN but it would probably be less resource intensive to have UDPMUX on a single port, I agree.

[xicilion]

I was wondering if each RTCPeerConnection could negotiate it's own NAT traversal via STUN/TURN.

From the logic of the code, even though multiple RTCPeerConnections share a single UDP socket in UDPMUX mode, each of them manages their own status separately and there is no difference compared to regular RTCPeerConnections. This means that the negotiation process for them is also no different from regular RTCPeerConnections.

[achingbrain]

I have forked node-datachannel as @ipshipyard/node-datachannel with all of the above patches applied.

Now CI is passing I'm going to merge this to allow further experimentation.