measure and decrease delay

[hannesm]

with #1 (and the monitoring branch which contains further fixes), this can be used as a reverse TLS proxy. the flow being that a client connects (TCP) to tlstunnel, which does the TLS handshake, and once established a TCP connection to the backend is established (and data being passed from the client to the backend).

when measuring delay (since the client has to wait for the TCP connection being established), what about opportunistically starting the TCP session once the TLS client hello is received? we do not (yet) have control / event thereof in the TLS stack, but it may be worth a try.

[hannesm]

another possibility is to always keep a TCP connecion to each backend open to be used for the next client (but this may due to mutable state actually be harder to write cleanly).