Delayed rediscovery of devices after interface address change

[bjester]

Observed behavior

When Kolibri's interface addresses change, like connecting or disconnecting from a network, we need to update Zeroconf so it can broadcast on those networks. In this process, we delete all dynamic NetworkLocations since some may no longer be valid.

If we didn't delete the NetworkLocations, we'd have to wait the TTL (60 seconds) of the mDNS records in order to receive their 'removal' events from the network. Conversely, since we delete them, if there are Kolibri's on more than one network the device is connected to and only one network experiences the change, we have to wait the TTL (60 seconds) in order to rediscover them on the network that didn't change.

Expected behavior

Upon updating interfaces, we should go through all Zeroconf instances and check if their IP is in the netmask of any bound network, and query an update for their 'service info' if true. This can use the recently vendored ipaddress lib.

User-facing consequences

Confusion when network devices are briefly invisible on the network

Steps to reproduce

Requirements:

• have access to our Kolibri WAN ZeroTier network
• have an existing Kolibri device on your local network

1. Start a provisioned Kolibri instance
2. Open the local network device modal, either through channel import or facility import
3. Observe only the existing Kolibri device on your local network should be visible
4. Connect to the ZeroTier network
5. Observe new devices are discovered from ZeroTier network
6. Disconnect from the ZeroTier network
7. Observe only the existing Kolibri device on your local network should be visible, but isn't
8. Wait some time, at least 60 seconds
9. Observe only the existing Kolibri device on your local network should be visible

Context

Kolibri 0.15+

[bjester]

Depends on addressing #10278 since we need the same information that ifaddr.get_adapters() returns on Android