This is a fork of grandcat/zeroconf. It is better maintained and running the
discovery command seems more robust with this version.

Otherwise SendDFU might fail, as cancelling the connection doesn't take
effect immediately.

The do not interfere with the firmware update, but can be relevant for
the client.

The discovery function gave up immediately when it encountered a
serial that didn't match the expected one, instead of continuing
to look. This is problematic if there are multiple Sensos on the network.

This helps simplify update logic, makes it easier to determine what mode
the discovered Sensos are in, and simplifies including Sensos both in
normal and bootloader mode in the discovery results sent to the client.

Stress testing after the refactor indicates that this is sufficient.

Switching to libp2p/zeroconf introduced a transitive dependency not compatible with older go versions.

Ensures privacy of state internals.

Co-authored-by: Johannes Emerich <[email protected]>

Devices try waiting for an IP via DHCP for ~30 seconds before
assigning themselves a link-local address, so in our typical
setup they are only going to announce services around 30 seconds
after the physical link is established. 60 seconds should be
more than enough.

It should report the delay time for `attempt`, rather than `attempt+1`.
`attempt` is still being reported as `attempt+1` for user-friendliness.

This were deleted in dividat#129, but were resurrected when merging main into
this branch.

This seems to improve robustness.

Background:

After rebooting to bootloader mode, the Senso needs some time
to start the TFTP service. Experimentation has shown that a
premature a TFTP write request to the Senso can potentially cause it
to enter a non-responsive state. The Senso can only be recovered from
this state via power-cycling. Sometimes even re-flashing the firmware
via USB may be necessary.

The previous 5 second wait already mitigated the risk quite well, but
during a stress test of performing back-to-back updates, the TFTP transfer
failed during the ~50th run. With a 10 second timeout, over 200 back-to-back
updates were performed successfully before shutting down the test script.

Make mDNS a requirement to run firmware updates. Reasoning:

- mDNS is used by 99% of installations
- The robustness of the update mechanism hinges on the insight into
  peer state provided by the mDNS records
- We can focus our resources on making this one mechanism work well

Leave it up to applications on how to communicate failure.

Co-authored-by: Johannes Emerich <[email protected]>