Add experimental support for QUIC

[tomaka]

I've been working on QUIC for the past few days, and I'm now opening this as a draft.
This PR points to my custom branch, which I think is pretty robust but needs to be finished. This Substrate PR itself is ready for testing and review, but not yet the libp2p branch.

From the point of view of Substrate:

• We now open a UDP socket on the port chosen by the --quic-port CLI option (which defaults to 30333). I've also added a --disable-quic CLI option in case we urgently need to disable it (for example if someone finds a bug somewhere in the QUIC code that crashes the node).

• This UDP socket is used both to accept incoming QUIC connections but also to establish connections to the respective UDP socket of other nodes. In other words, all communications go through this single socket.

• At the moment, since support is experimental, we refuse all incoming QUIC connections by default. One can listen on incoming QUIC connections by passing --listen-addr /ip4/0.0.0.0/udp/30333/quic. Note that the port passed to --listen-addr has to match the one of --quic-port, otherwise the listening will fail.

• There is a small caveat at the moment: if you spawn two nodes on the same machine with the default CLI options, they will both try to open a socket on the same UDP port, and one of them will fail. Contrary to TCP/IP, the consequence is that the node which failed to open the UDP port will also be unable to dial the QUIC addresses of other nodes. This is pretty annoying, and I'd be in favour of automatically trying multiple ports if the default one fails to open, but this needs to be brainstormed because of the interaction with --listen-addr.

Before we can consider merging, we need to:

• Review and merge the libp2p changes.

• Modify the bandwidth measurement system of libp2p. As you can see in this PR, there is a TODO indicating that QUIC cannot be plugged in libp2p's existing bandwidth measurement system. We should in my opinion change this bandwidth measurement to only expose one AtomicU64 for the incoming bytes and another AtomicU64 for the outgoing bytes.

• Wait for a new release of rustls in order to support non-web TLS certificates (New release rustls/rustls#368)

• After rustls has gotten a new version, wait for the quinn-proto and x509-signature libraries to upgrade to it.

The last two points are purely "administrative" and can unfortunately take quite a long time.

[Demi-Marie]

@tomaka I maintain x509-signature and can promise that it will be kept up-to-date.

[tomaka]

Closing this PR. This was just a (successful) proof of concept, and considering the many conflicts and API changes it doesn't make sense to continue this branch.