investigate: switching the libp2p transport from tcp to quic

[istae]

Background:
quic transport layer, being based on udp, may bypass certain firewalls of certain countries, plus it brings latency benefits

janos writes

so I would suggest to try it again with one consequence, we have made possible especially to support multiple transports on libp2p as underlay addressing. so it should be checked that this is functioning still correctly in addressbook, handshake, hive, logging and so on. so with quic enabled nodes will have at least two underlay addresses that can be advertized and nodes in the network will advertize the underlay that they have connected to two different nodes can send two different underlay addresses for the same node if one connect with tcp and another with quic. also, quic should work faster as it takes over the multiplexing from libp2p

It's been suggested that running both tcp and quic may be a requirement.

Testing will be in 3 steps.

• Testing on a private cluster (private testnet)
• Testing on a private cluster with half the node running TCP and other half running TCP and QUIC. Bootnodes MUST advertise both transports.
• Deploy and test in a new network with nodes running in china and in eu.
• Test on public testnet.

[istae]

quic on by default but can be turned off by flag
and when nodes try to connect, they should try quic first
and fallback on peer's tcp address, if any

[nikipapadatou]

Before we proceed with testing this in chinese nodes, we are testing in EU. Once we succeed with this, we can move to the next step:
Ask node operators from china to help us with deploying more nodes to see the performance. Also we can consider the trusted operator program partners (TOP) to get benefit from them.

[nikipapadatou]

Putting the current on hold, because it seems that the QUIC addition did not bring the expected results.
https://hackmd.io/tLCzlMIuQCORXPfygngqxg?view