Introduce SlowOpenToxic to approximate the TCP handshake latency

[stribioli]

As discussed in #123, the TCP handshake is performed by the kernel, so toxiproxy cannot inject latency there. Therefore, effects of latency on connection timeouts cannot be tested using this tool.

However, a user might be interested in the overall effects of latency from an application point of view. That is, the end-to-end effect on an entire conversation (TCP connection, application request, application response).

Using the LatencyToxic only, this end-to-end effect is not accurately modeled, because the initial RTT would be missing. This pull request introduces a new toxic, SlowOpenToxic, that simulates the handshake latency by adding a delay to the first data packet only. I hope you'll find it useful!

Latencies breakdown

In reality, you would have:

• a 1-RTT delay on the TCP handshake
• a 1-RTT delay on all subsequent data packets

Using Toxiproxy, with a SlowOpenToxic and a LatencyToxic (with the same delay, equal to 1 RTT), you would have:

• a 0-RTT delay on the TCP handshake
• a 2-RTT delay on the first data packet (1-RTT delay added by SlowOpenToxic and 1-RTT delay added by LatencyToxic)
• a 1-RTT delay on all subsequent data packets (added by LatencyToxic).

Implementation notes

• The new toxic is derived from LatencyToxic. Once the first packet has been processed, a persisted State records the event and makes the toxic warm. From that point, this toxic is transparent.
• I extracted a block from the LatencyToxic tests (doLatencyRound) in order to:
  • Re-use it in the SlowOpenToxic tests.
  • Run it multiple times to test the different behavior between LatencyToxic and SlowOpenToxic. To do this, I also tweaked the harness (at toxic_test.go:69) to process multiple packets, instead of stopping at the first one.

[stribioli]

I have signed the CLA!