With the simplexmq change this depends on, the core reconnects to the servers
on every online network event, so the event must also be sent when the network
type stays the same but it is a different network or an address was removed
(another Wi-Fi network, a new IP address after internet loss) - the connections
via the previous network are dead, and the OS reports it only after ~15 minutes.
Added addresses do not affect existing connections and are not reported,
unless there were none before. The event is not sent when the core
already has this network info for the network its connections are made via.
- android: track the Network handle and the link addresses in NetworkObserver,
handle onLinkPropertiesChanged, and do not report online after an offline
event that was not sent yet.
- android: the observer is serialized, and the removed addresses are counted
rather than compared - an address removed and assigned again also leaves
the connections made via it dead, so the count is what the next report is
deduplicated against.
- android: the loss of a network that is no longer the current one is not
reported - it is lost after the network that replaced it became the current
one, and the connections are made via that one.
- ios: compare the local addresses of the interface the path uses and its
gateways - NWPath has no network identity and no addresses.
- a report that was not accepted is repeated when the next event is received.
- what was reported is reset when the chat controller is created anew, so that
the network info is reported to it and the reports for the previous one are
dropped.
- android: the wake lock taken for the report is released when nothing was
sent or the network is offline, instead of being held for its full timeout -
the events that report nothing are new, as the info the core already has for
the network its connections are made via is not sent again.
The controller was read twice - checked and then read again inside the command -
so replacing it between the two failed the command, and on iOS reading it again
terminates the app, as getChatCtrl() is a fatalError when it is not set. It is
now read once and passed to the command.
A failed report is not alerted about, as the network info is reported
automatically: the command is sent with sendCmd rather than sendCommandOkResp,
which shows an alert.