ndt7: save application level RTT samples

[bassosimone]

In #188, we have implemented the mechanism for measuring application-level pings RTT but we are not currently saving it. This should be done, to make the data actionable. We need to update the spec to mention this piece of data and change the code to save it.

[bassosimone]

BTW, issue #201 seems to be a case where the RTT is actually 20-ish but BBR thinks it is much smaller, therefore, it would be beneficial to see what applevel-RTT says about the connection.

[darkk]

I've done some shallow refactoring to include base time.Time reference, save websocket-ping RTT and send it to client together with TCPInfo sample. Unfortunately, measuring L7 RTT while doing /upload or /download produces significantly skewed results those are hundreds milliseconds apart. That's expected at least due to TCP HOL, so I've added /ping endpoint to measure RTT cleanly.

The test produces expected difference between L7 and L4 RTT when TCP proxy is present on path. E.g. Tor Browser measures L7 / L4 RTT as 302.6 / 5.9 ms from my location in St. Petersburg to a VM in London.

It's also theoretically possible to modify /download spec to collect several L7 RTT samples before pushing the actual data to avoid HOL and gather the data from existing clients. It's unclear to me how it may affect existing logic at clients as I'm not that aware of the client code that is already rolled out.

What do you think, should it be /ping or should /download spec rather be amended?

[bassosimone]

@darkk considering how other speed tests work, I think may be preferable to include an application level /ping phase to the experiment. I'm significantly less happy about modifying the expected behavior of the client during /download or /upload because that would complicate the implementation and we wanted to keep the client's implementation very easy.