dcutr: Improve VPN hole punching by subtracting default gateway RTTs from protocol RTT measurement

As we were discussing protocol improvements in #487 I'm just leaving this here as a not fleshed-out food for thought:

Currently, the protocol has the hidden assumption that the RTT measurement from one node to the other is equivalent to the RTT between both NAT's. This assumption holds true for most home networks where the router is a millisecond away. However, for VPN'd peers it's likely not true.

Let's say A wants to hole-punch B. A opens a dcutr stream via a relaying peer R and sends the first CONNECT message. B replies with a CONNECT message - but now, this message also contains the observed RTT of B to its default gateway (which could be a VPN exit node - not sure if default gateways == VPN exit nodes). In the meantime A has also measured the RTT to its default gateway. Upon receipt of the second CONNECT message at A, A knows

1. the RTT between A and B,
2. B and its default gateway
3. the RTT to its own default gateway.

A sends out the SYNC message and in the current specification A would wait 1/2 the RTT between A and B (1.). The change here would be to wait for:

1/2 RTT A to B + 1/2 RTT B to its default gateway - 1/2 RTT A to its default gateway.

I hope, I got the different RTT's right.

cc @physikerwelt

Start with the protocol discussion in issue #488 and the related issue #487; no file, test, or entry point is named. Clarify the RTT assumptions and scope with maintainers, then document an agreed protocol change and its completion criteria before implementation begins.