New gossip_net backend using libp2p

[emberian]

This is the revival of the tmp/cmr/net2 branch rebased onto develop.

Some important user-facing changes:

• No separate discovery/communication/etc ports. One port for all public daemon communications.
• Automatic port forwarding with UPnP. If your local network supports UPnP, there should be no configuration required.
• Local peer discovery. If your local network supports mDNS broadcast, coda daemons will automatically discover each other. This includes several daemons on the same machine- no more building peer lists!
• New libp2p keypairs. These are managed the same as our key pairs with secret_file. Without configuration, key pairs are ephemeral and will disappear when the daemon restarts. (TODO: should we instead persist the keypair? does it matter for non-infrastructure?)

Some important internal changes:

• All daemon-daemon connections are now authenticated and confidential.
• Connections are no longer transient and per-request. Individual requests get multiplexed as their own stream over the one connection between the peers. This is analogous to HTTP/2. Outgoing connections will appear to originate from the libp2p listening port, vs some transient port.

Outstanding details:

• Trust system needs to get augmented to track Peer.t instead of just an IP. Until then we can't implement ban_notify (Add Peer.Id.t to ban notifications and notify them when banned #4093, Trust system: track full Peer.t instead of just IPs #4096).
• Libp2p has little per-connection structured reporting, some things we currently penalize trust for are not detected (eg opening a libp2p connection without also
  opening a coda RPC stream) (Manage more malfeasance in libp2p #4098).
• New pubsub allows banning senders by peer ID. We currently don't do this but we should ban peerIDs that originated bad info and not just the IP of the whoever relayed it to us (Trust system: track full Peer.t instead of just IPs #4096).
• Current pubsub validation flow goes a bit against the libp2p grain, and it's not clear to me that the current behavior will survive this libp2p PR. There's an inline comment near the should_forward_message impl (Rework should_forward_message use in Gossip_net.Libp2p #4097). done
• Connection limit enforcement (Set/rework libp2p connection limits #4095)

Other changes:

• Rips out the last vestiges of old membership, which aren't in use.
• The connection info in envelopes is much more accurate now. We shouldn't start trusting it just yet due to some future vagaries around relaying.
• bump nixpkgs version

Future improvements:

• IPv6. There's a hardcoded IPv4 assumption in the helper around IP filtering.
• Investigate libp2p autorelay. This should help nodes in restrictive networks achieve better connectivity, but has a host of problems.
• Intelligent request routing. I believe we can use the "provider" feature to, at the very least, only send eg sync/bootstrap requests to nodes who believe themselves to be in sync. There are other options.