NAT traversal: Support for WebRTC transport in libp2p

[aarshkshah1992]

Please see #188 for some historical discussions and motivations for this issue.

• A WebRTC transport will enable better connectivity between js-libp2p and go- libp2p peers as the ONLY way to accomplish that right now is through websockets.
• WebRTC also has some NAT traversal mechanisms built in (albeit, not as strong as what we can accomplish ourselves with QUIC hole punching)
• We need to review https://github.com/mtojek/go-libp2p-webrtc-star and take it to completion.
• We will have to change the use of “centralized” STAR signaling servers in the above to use relays instead for signalling. It will be something similar to relay/DCUtR: Add Direct Connection Upgrade through Relay protocol specs#173.

Some design notes on using relays instead of STAR signalling servers can be found at:
libp2p/js-libp2p#385 (comment)

[aarshkshah1992]

cc @jacobheun

Please flesh out more details here if you feel something is missing at this stage of the discussion.

[backkem]

Can you elaborate on the differences between your quic and webrtc's hole punching? Is this documented somewhere?

[aarshkshah1992]

@backkem

IIUC, WebRTC's hole punching dosen't work well with five tuple NATs i.e. NATs that allow incoming UDP packets from a ip:port ONLY if they've sent an outbound UDP packet to that ip:port.

cc @willscott if you have more questions.

[aarshkshah1992]

cc @yusefnapora for thoughts and comments.

[p-shahi]

closing in favor of libp2p/specs#412 and #1655