iperf3 send-then-receive test

[candlerb]

Suggest a new version of bi-directional throughput test, which runs iperf3 immediately followed by iperf3 -R in double the timeslot.

Advantages:

• works behind NAT
• send and receive are done at (almost) the same time, so drops in throughput are more easily correlated
• lead participant is your local node, so you get priority in the "friendlies" group
• archiving is done by the local node, so you're less dependent on the other end having up-to-date software
• only requires a single task in the scheduler: in that respect it's similar to #883, but without using a new version of iperf3

[mfeit-internet2]

A few points on this (and probably why it hasn't been done yet):

Architecturally, we're not set up for one run of a task to produce multiple, dissimilar results. The multi-result arrangements that are used for streaming latency work because each result is for the same measurement and it looks like an identical test that ran multiple times. This case would have alternating results being A-to-B and B-to-A, and there'd be no way to tell which is which.

We've discussed the idea of "bonus material," where one measurement could synthesize others (e.g., the job was to measure RTT and a loss measurement was a side effect). There would have to be some architectural changes to the innards of pScheduler to do that; it's a nontrivial effort and, last we discussed it (this spring), the demand for it wasn't there.

We could do a simultaneous throughput test between pSchedulers or a one-after-the-other version that would work single-ended. It would have to be a separate test from throughput and would have a unique set of tools.

Operating from behind NAT can be handled by running the same test twice and using the reverse switch on one. That also covers the "friendlies" case and archiving being done on the local node.

[mfeit-internet2]

This might be better done as a single bidirectional test as in #883 .