Basic project flare (hole punching) test

[BigLep]

Done Criteria

We have a test-plan that can be run as part of go-libp2p CI that spins up two go-libp2p nodes behind separate NATs and confirms that hole-punching succeeds within the allotted 3 retries.

One go-libp2p nodes should be using the latest go-libp2p code. The other should be using the previous release. (We do this to ensure we haven't deviated from the spec.)

Why Important

This is critical for ensuring we don't regress on project Flare functionality. Once libp2p consumers like go-ipfs start enabling hole punching in go-libp2p by default, users are going to start having access to more content. We want to make sure future releases of go-libp2p don't regress on this behavior, effectively taking away content that was previously accessible. We need this automated because manual testing of hole punching scenarios doesn't scale.

User/Customer

go-libp2p maintainers to ensure not regressing.
This gives go-ipfs, Lotus, etc. confidence about including the functionality by default.

Notes

1. At least as of 2022-03-16 there is active effort to get Testground as a Service infrastructure up and reliable so test-plans can be executed as part of CI. Since we have high confidence that this is coming and that it will land, we can resolve this issue once we have the test plan that passes manually for now.
2. NAT functionality in Testground will be needed. This is being tracked here: Enable creating nodes behind NATs and/or firewalls testground/testground#1299
3. A key thing here is to make sure we don't break compatibility from the spec. This is why we don't test two identical libp2p nodes. Even better than two go-libp2p nodes would be a rust-libp2p and go-libp2p node.
4. There is a SimOpen PR here (Simopen Tests #16 ) in case it's of use.

[marten-seemann]

Closing in favor of #126. Sorry for creating a duplicate.