feat: add NetworkCookie option for isolating testnets

[ivan4th]

Motivation: sometimes, it's necessary to be able to isolate testnets from the real networks, avoiding some hard-to-diagnose issues. This was previously achievable using Noise Prologue, but was impossible for e.g. QUIC transport.

This adds NetworkCookie libp2p option that prevents peers with different NetworkCookies from connecting to each other. The peers without a NetworkCookie can't connect to or receive a connection from a peer with a NetworkCookie.

This is not a replacement for private networks, just a safeguard against unintended testnet / mainnet interaction.

This PR replaces #2645 which only worked for QUIC and didn't have proper "facade". This change works for all transports.

The usage is as follows

nc := []byte{...}
// or:
// nc, err := crypto.ParseNetworkCookie("0123ab")
// ...
h, err := libp2p.New(libp2p.NetworkCookie(nc), ...)

Implementation details:

• for TLS, an extra field with the network cookie is added to the TLS extension in a backward-compatible way; the field is included in the signature
• for Noise, Noise Prologue is used for the network cookie. In case of WebRTC, the prologue is extended with the network cookie if it is specified
• for the insecure transport, an extra field is added to the exchange message in a backward-compatible way

Additional implementation notes:

• if you think that "network cookie" is not the proper name for this construct, it can of course be renamed
• instead of adding an extra argument to the transports / security transports, I've made the network cookie "attachable" to the private key. This might seem a bit strange, but it reduces incompatibilities with existing codebases.

[marten-seemann]

This is a massive change. If you want to make this happen, this will need proper specification in the specs repo before we can make any progress here.

[ivan4th]

@marten-seemann The change is not that big if you don't count the tests, but sure, as there are (backward-compatible) changes on the protocol level I will work on a PR for the specs repo.
It's worth noting that the feature will become unnecessary when all the transports get private network support, but IIUC that might take quite some time, so it may make sense to have NetworkCookie for a while and then eventually deprecate it.

[Stebalien]

This is a wide-reaching spec change and it's not clear that it's the right solution. It definitely requires a spec proposal so we can discuss alternatives.

The usual way to fix this is:

1. Create independent DHTs by using the ProtocolPrefix DHT option (designed to solve exactly this problem).
2. Use separate pubsub topics for each network.

Otherwise, it's impossible for peers to connect to both networks at the same time which is actually desirable in some cases. To be clear, private networks were never intended to be used as a way to isolate networks this way, they were designed to provide authentication and privacy.

[Jorropo]

I think you should rebrand this as PNET v2 (and make a specification).
They both seems to achieve the same thing, I havn't red the code enough to know if NetworkCookie is private information, but that doesn't sounds very hard to ensure we never leak the cookie.

---

This wouldn't solve the problems raised by @Stebalien however.