Fix relay

[brad-defined]

Relay creation may race, meaning a host that has sent a CreateRelayRequest may receive a CreateRelayRequest message for the exact same tunnel, before receiving a CreateRelayResponse. When this happens, a relay's locally stored remote index will be 0. When a corresponding CreateRelayRequest arrives, it'll have a non-zero value for that remote index. The current code on Master detects this mismatch as a broken relay, and tears down the relay state. Destroying this relay state breaks all possible connectivity for the tunnel.

To work in all cases, once a relay's index is created and advertised (in a CreateRelayRequest), it should never be torn down until the associated HostInfo is destroyed. This PR updates the handling of CreateRelayRequests to avoid tearing down relay state in these detected mismatch cases.

I also added some synchronization around the Relay struct, using an atomic pointer.

I edited an existing test that could reproduce errors on Master, but which runs correctly with these updates. (Nate made the test.)

[brad-defined]

Pushed some updates:

(1) Sometimes a HostInfo that is not the main HostInfo sees traffic, which prevents it from being deleted by ConnectionManager. Since no more outgoing traffic is sent over this non-main HostInfo, it never cycles back through ConnectionManager. PR updates ConnectionManager to place a HostInfo back onto the watch list if traffic is seen as received during the deletion phase.
(2) When tearing down all tunnels, we must iterate all Indexes, not all Hosts (which will not return non-main HostInfos).
(3) Included a test that @nbrownus wrote that sussed out some races through relays
(4) Sped up some deletion timers during tests to 4 seconds, in order to make tests that wait for hostinfos to be removed to run faster.
(5) Included some locks around hostmap access during tests, which occasionally raced with Nebula code accessing the same main host maps.
(6) Modified HostInfo teardown code to take multiple host infos into account. Only removes Relay state if the HostInfo being deleted is the final HostInfo for that vpnIp in the hostmap.
(7) Updated tests to not return a copy of RelayState, as this could copy a locked mutex and deadlock the tests.

[nbrownus]

I think relayHostInfo -> relayVpnIp.

Probably would be good to do a separate pass to make sure all logs are using the same field names.