Should we always emit an initial reachability event?

[MarcoPolo]

We currently only emit an initial reachability event when we set some forceReachability. Normally we wait until we have some new information before emitting the our first reachability event, thus assuming if there's no event then we are in the "unknown" state.

This assumption of initial state complicates users of this event stream. Take for example this AutoRelay code. It waits for a reachability event before doing anything. Arguably It should start the relayFinder with our initial unknown reachability. As is, this will wait until we transition to private to start the relayfinder. This is likely a bug here (although in practice may not be too obvious).

To fix this bug with autonat's current reachability behavior is quite tricky. You want to handle two cases:

1. If no event is on the bus, assume we are in the unknown state. But we can only
2. If there is an event on the bus use that information (e.g. we force public reachability)

The fix for autorelay would look something like this. It's pretty gross.

On the other hand, you could argue that we don't want to start the relayfinder initially at all until we observe we are private in order to avoid starting the relay finder in case we are public. I'd argue for explicitly defining that in the autorelay code rather than relying on the default unknown assumption. Another thing to keep in mind is that if AutoNat only receives "unknown reachability" observations, we will never start the relay finder.

[sukunrt]

Regarding autorelay:
I think we should start it with some boot delay when we are in state Unknown and obtain reservations. However, I in state Unknown the basic host should advertise both its direct public addresses and it's relay public addresses as we really don't know what our reachability is. Unknown might as well be Public.