Ticks taken while the OS reported no network were skipped, but they still
advanced the exponential backoff, so a peer could be tens of seconds from its
next attempt by the time connectivity returned. Recovery then depended on a
signal or relay event, which never arrives when both stayed up across the
outage, e.g. a short airplane mode toggle over Wi-Fi. A peer parked in ICE
hourly mode stayed there for the same reason.
React to the offline-to-online transition directly: re-arm the reconnect
ticker and reset the ICE retry state, so the peer retries at once. Add
netstate.Changed for callers that own a select loop and cannot block in Wait.
On mobile the client kept dialing management, signal, relay and peer
connections while the device had no usable network at all (airplane
mode), burning battery for attempts that cannot succeed. Stopping the
engine is not an option: tearing it down destroys the TUN device, and
traffic can leak outside the tunnel until it is rebuilt.
Add client/netstate, a small gate the platform feeds from its own
connectivity callbacks. Every reconnection loop waits on it instead of
retrying blindly, and resets its backoff when the network returns so
recovery is immediate. The state is injected through functional options
and consumers hold a *State that may be nil, so every platform that does
not report availability behaves exactly as before.
The relay quick-reconnect rechecks availability after its 1.5s wait: the
disconnect that triggers it is usually the first symptom of the network
going away, so the flag typically arrives while it sleeps.
Report the suspension to the UI as well. peer.Listener grows
OnStateChanged with a typed ClientState, re-exported across the gomobile
boundary as integer constants, and the notifier maps Connecting to a new
NoNetwork state while the OS reports no network, so mobile clients can
show "no network available" instead of a misleading "connecting".
Finally, exit the client retry loop cleanly when its context is
cancelled. backoff.WithContext surfaces the bare context error, which
callers could not distinguish from a real failure — on Android that
turned an engine restart into an unrecoverable error.
