Rework peer-to-peer route handling about zerotierone HOT 1 CLOSED

Peer::WanPath et. al. are messy so this code is going to be reworked at some point soon. This will probably be replaced by a first-class Route class.

Route will have a notion of confirmed and unconfirmed routes, which solves issue #20 by allowing new routes to be learned lazily as they are now but introducing a preference for routes that have been authenticated.

This may include a reworking of how relaying is done, with getBestSupernode() and friends in Topology replaced by getRouteToPeer() or something like that. This would allow all routes to be compared and maintained in a single database in each Peer, which wastes a very small amount of memory in exchange for simplicity. This would also enable an easy algorithm for detecting and recovering from route loss.

Typically conversations over networks are two-way. When something is sent to a peer, an expectation of a reply could be registered. If incoming traffic never comes, a PROBE is sent to all known routes to re-select routes based on latency and recentness of activity. This would result in, say, 10 seconds or so of loss of connectivity if a supernode failed, and also prepares us for further decentralization.

from zerotierone.