Proactively seek, and distribute external surface addresses
This patch introduces a new "self-awareness" behavior which proactively queries peers for external surface addresses and distributes them via PUSH_DIRECT_PATHS. This has the effect of making ZT more responsive to interface changes.
Current behavior:
Previously, this type of information was only mediated via RENDEZVOUS and was only triggered when the client detected that it no longer had a single alive path to a peer. While PUSH_DIRECT_PATHS would correctly (and often) send local addresses, this was not the case for external addresses collected from response HELLOs. This would lead to situations where only one physical address would be distributed to peers. Additionally, if a new physical interface were to be made available to the client, the client would correctly bind to it but never seek information about its external mapping from a peer, and thus the new physical interface would remain unavailable for other peers to learn about until all paths on the previous interface have expired which can take a couple of minutes. In traditional usage of ZT this is not usually a problem, but it becomes a problem in the following scenarios:
Network interfaces go up and down while ZT is running (e.g. switching to LTE or WiFi from a wired connection)
Network interfaces are added or removed in multipath setups
Proposed behavior:
I propose that normal full HELLOs are sent not only on the first interface in use, but all interfaces. This causes planets to respond with a HELLO containing the surface address for each interface. We then collect each address using SelfAwareness::whoami() and distribute them via the normal PUSH_DIRECT_PATHS mechanism.
Add a method to "kick" the refresh thread and re-post the tokens in the case where the thread is somehow still running & controller pushes out an AUTH_REQUIRED. This situation happens in a corner case still under investigation where the controller pushes out many copies of the network config repeatedly
