Implement retransmission scheduling heuristics

[grandrew]

see https://github.com/grandrew/vtrunkd2/issues/167#issuecomment-168802176

in order to guarantee optimal channel characteristics we need to consider several higher-order factors:

• are we really a telemetry?
• is the channel enough for telemetry in R_MODE?
• do we have enough resources to ever fulfill the requirements to send?
• what to sacrifice if we do not?
• we see a suspicious lag, do we have an ability to resolve the issue by retransmitting late packets? #67
• if the channels are very unstable, how do we schedule send in R_MODE? is current parameter time resolution enough?

[grandrew]

see for example this ping session from SPS:

user@nbn-train1:~$ ping 10.5.0.27
PING 10.5.0.27 (10.5.0.27) 56(84) bytes of data.
64 bytes from 10.5.0.27: icmp_seq=3 ttl=64 time=482 ms
64 bytes from 10.5.0.27: icmp_seq=4 ttl=64 time=122 ms
64 bytes from 10.5.0.27: icmp_seq=5 ttl=64 time=91.9 ms
64 bytes from 10.5.0.27: icmp_seq=1 ttl=64 time=4765 ms
64 bytes from 10.5.0.27: icmp_seq=6 ttl=64 time=142 ms
64 bytes from 10.5.0.27: icmp_seq=2 ttl=64 time=5056 ms
64 bytes from 10.5.0.27: icmp_seq=7 ttl=64 time=113 ms
64 bytes from 10.5.0.27: icmp_seq=8 ttl=64 time=154 ms
64 bytes from 10.5.0.27: icmp_seq=9 ttl=64 time=144 ms
64 bytes from 10.5.0.27: icmp_seq=10 ttl=64 time=133 ms
64 bytes from 10.5.0.27: icmp_seq=12 ttl=64 time=468 ms
64 bytes from 10.5.0.27: icmp_seq=11 ttl=64 time=1933 ms
64 bytes from 10.5.0.27: icmp_seq=13 ttl=64 time=155 ms
64 bytes from 10.5.0.27: icmp_seq=14 ttl=64 time=137 ms

in this case the daemon was only sending pings and as soon as it detects that it may retransmit packets faster it should do it - to prevent such massive reordering and lags