add a test plan that measures the RTT of libp2p handshakes

[marten-seemann]

The test plan will test that the libp2p handshake completes in the expected number of roundtrips. For example:

• the QUIC handshake should take 1 RTT
• the TCP handshake should take 4 RTTs (1. 3-way TCP handshake, 2. multistream negotiation of security protocol, 3. security handshake, 4. muxer negotiation)
• when using early muxer negotiation (Tracking Issue: early muxer selection go-libp2p#1789), the TCP handshake only takes 3 RTTs

This can easily extended to test that moving the security protocol into the multiaddr (libp2p/specs#353) saves another RTT.

The test plan will need to build on the cross-version test (or maybe the cross-implementation test). This will allow us to assert that while new go-libp2p versions make use of all the performance improvements and handshaking takes fewer RTTs, we're still remain backwards-compatible.

In the long term, this test will probably replace the ping test plan, as it tests strictly more than the ping test.

[marten-seemann]

This effort is currently blocked by testground/testground#1488.

[marten-seemann]

With the new wo-testground setup (we really need a better name for that…) this should be not too difficult to implement. I hacked a PoC in the rtt-test branch, although that code is by no means clean.

There are 2 main things we need to solve / standardize:

1. We need a launcher script (to be mounted into the container) that runs some setup before the node is started (executing the tc command to get netem to apply an RTT to the interface).
2. We need to specify the name of a results directory (/results?) and a JSON format how we export the measurements. I suggest exporting both the handshake latency and the latency determined via ping.

We can then check that the handshake latency matches what we expect. From my initial test, it looks like with a 100ms RTT, we end up with non-ambiguous results (e.g. a handshake that’s supposed to take 6 RTTs would take 615ms). We’ll need to check that this also holds on CI (reliably!). As long as the value is closer to N than to N+1, we should be on the safe side.

[p-shahi]

deferring this in favor of the work in #63