Nat hole punching for discv5.2

[emhane]

Closes #133. This implements a new protocol with the same goal as the rendezvous protocol outlined as draft in the issue, that is to hole punch NATs, but with a different method. The protocol is tailored with more precision after discv5's design to remove identified attack vector's that the rendezvous protocol introduced like the 2-for-1 message triggering and adding mechanisms to make NAT hole punching produce almost only necessary overhead for the network at whole by taking parameters like connectivity between relays and targets into account, for example that as the time an initiator stores a relay to a target increases, the connectivity guarantee between that relay and the target decreases. The new discv5.2 spec contains the new hole punching protocol and the rationale is still in review.

Testing with my discv5-cli fork.

[emhane]

for using nat:ed peers discovered by this devp2p nat protocol in lighthouse, we will have to modify these lines in libp2p to iterate through all the tcp connections instead of just the relay's reservations, so that libp2p's hole punching code will work with relays passed on from discv5. here in discv5, I will add the relay used into the RequestCall struct, and add the event "discovered nat:ed peer", to pass the relay back to lighthouse along with the nat:ed peer upon established connection. lighthouse peer manager will have to combine the two peers into a p2p-circuit mulitaddr @AgeManning

https:/libp2p/rust-libp2p/blob/30024f38d41804599a64d00934bf169b146e3ea3/protocols/relay/src/behaviour.rs#L498C16-L502C18

@jxs nice that you want to get involved. perhaps this is smthg you could dig into?

[AgeManning]

I think we've got this to a state that is clean and workable.

I think there is more machinery around ENR support for NATs, self-identification and backwards compatibility to work on. But these can be separated as future PRs.

This work should be used as a base for the 5.2 upgrade, imo.