Add Bounceback test

[davidBar-On]

• Version of iperf3 (or development branch, such as master or
  3.1-STABLE) to which this pull request applies:
  master

• Issues fixed (if any): Support for responsiveness measurements #1725

• Brief description of code changes (suitable for use as a commit message):

Suggested solution for adding Bounceback test to iperf3, using a new --bounceback option. The implementation options are based on subset of the iperf2 options, but there are some differences in the approach to simplify iperf3 code changes (assuming I understood iperf2 implementation well enough ...). Following are the main approach considerations:

• Instead of supporting --bounceback-period option, the bounceback test period is the Report Interval (-i). That allows using the interval reporting mechanism, instead of adding a separate one. During the interval period, several bursts of bounceback messages may be sent, but the statistics are reported once per interval.
• The protocol used for the bounceback messages is the same protocol used for the throughput test (i.e., default TCP, UDP with -u). This is to allow creating the bounceback stream as part of the test streams creation. Practically, it may be that only TCP (and SCTP) are reliable.
• Instead of supporting --working-load, the normal iperf3 throughput tests are used as the workload. That makes all the iperf3 tests options available to the bounceback workload (-P, -R, --bidir, -b, etc.). For running only bounceback test, -P 0 should be used.
• Statistics are about the bounceback round-trip time (RTT). The bounceback RTT is calculated at the client by subtracting the server's processing time from the total RTT. With this approach, the clock in the client and server does not have to be in sync. Of course, not all the client/server overheads are eliminated from the RTT, but I am not sure how much and how important this is.
• The bounceback statistics are reported in a separate [BBK] line. Adding the statistics to existing interval/summary report lines would be more complex.
• Only client to server bounceback test is supported. I am not sure if this is different from iperf2, but it seems that this should be sufficient, as the report is about the round-trip time.
• TCP bounceback streams is always using TCP_NODELAY (not an option) and there is no option to set TCP_QUICKACK.

The --bounceback option receives the following 4 parameters (all are optional):

1. Number of messages in a burst (default is 10)
2. Number of bursts per Report Interval (default is 1)
3. Client to server request message size (default is 100 bytes)
4. Server reply message size (default is request message size)

Some open questions:

1. Folloing is an example of the bounceback (BBK) report line. Is it o.k.?

[BBK]   2.00-3.00   sec  count: 30, avarage: 0.449ms  min: 0.346ms  max: 0.605ms  stdev: 0.452ms

Should it be more like iperf2 logs, e.g. something like:

[BBK]   2.00-3.00   Count=Average/Min/Max/Stdev: 30=0.449/0.346/0.605/0.452 ms

2. Should -P 0 be the default when --bounceback is specified? I.e. should the default be no workload, and if needed workload should be added using the -P option?
3. For TCP bounceback tests, is it important to support options to disable TCP_NODELAY or to support TCP_QUICKACK?
4. How important are the iperf2 options --bounceback-hold and --bounceback-txdelay? Is it important that any of them will be added to iperf3?