Upgrade to using /ws and /p2p-circuit

[ghost]

Currently the rendezvous server is a bandwidth bottleneck by design -- all peer connections go through it, and we unfortunately can't add more instances without making the server capable of federating with other servers, at which point we'd be rebuilding parts of libp2p, outside of libp2p.

We can get the same functionality without the server-relay component, where p2p-websocket-star would do only discovery (and for backwards compatibility, the transport would transparently use a relay.)

Imagine a very simple scenario with three browser nodes QmA, QmB, QmC, and one relay node QmRelay. To each new browser node, the rendezvous server emits addresses of already present nodes:

• /dns4/relay.libp2p.io/tcp/443/wss/ipfs/QmRelay/p2p-circuit/ipfs/QmA
• /dns4/relay.libp2p.io/tcp/443/wss/ipfs/QmRelay/p2p-circuit/ipfs/QmB
• /dns4/relay.libp2p.io/tcp/443/wss/ipfs/QmRelay/p2p-circuit/ipfs/QmC

We should already be capable of exactly this ^ right? @dryajov

For backwards compatibility, the /p2p-websocket-star transport would transparently make use of the /wss and /p2p-circuit transports. It'd basically transform a currently used address like /dns4/ws-star.discovery.libp2p.io/tcp/443/wss/ipfs/QmA to another as shown above.

[daviddias]

@Steverman you did a great job with libp2p/js-libp2p-webrtc-star#130, wanna tackle this one here too?

[Steverman]

I can't promise on this one. Very busy this month (this includes December).

I was not satisfied with my other PR, so I may have to revisit it at some point.

[dryajov]

@lgierth I missed this issue somehow.

To your question, yes, we should be able to emit /p2p-circuit addrs, at which point, it's possible to dial those nodes over the relay.

[mkg20001]

PR #43