Pull hostmap and pending hostmap apart, remove unused functions

[nbrownus]

The main HostMap has concerns that the pending host map does not and has led to bugs in recent changes.

This change puts HandshakeManager in charge of its own dedicated maps that share some similarity with the main HostMap but lacks all the extra cruft. This also removes some unused code from the main HostMap as a result of the split.

My main concern is: HandshakeManager.AddVpnIp will go for a write lock immediately, Interface.getOrHandshake won't attempt check the pending hostmap before making a call to this function. This avoids a read lock to write lock trading race that lead to the overcomplication of Interface.getOrHandshake long ago. The concern is when restarting nebula on a busy host with many tunnels, there will be a period of strong write lock contention until the tunnels form or the services using the overlay slow down transmitting until replies come in.

If we believe this is an issue I can go back to behavior similar to the old way that still sets us up to simplify Interface.getOrHandshake in the future with a read lock check and a write lock check before proceeding to add.

[maggie44]

I am looking to poll the hostmap every 4 seconds to be able to keep an up to date list of connected devices for use on a dashboard. Would that be blocked by these locks or create a lock itself that would prevent devices joining?

[nbrownus]

That would require a read lock and could slow down a few interactions but its probably fine. Control.ListHostmapHosts or Control.ListHostmapIndexes would be your best bet at accessing that information as well.

[maggie44]

I've been using hostMap := Ctrl.ListHostmap(false) exposed by *nebula.Control, but looks like it is doing the same thing (not accounting for anything in this PR mind).

It could be 100,000s of nodes, but presumably it is just a lookup of data already gathered, so thinking it shouldn't be a noticeable delay or lock 🤞

[wadey]

Looks good except one comment