Zeroconf

Technically backwards incompatible:

- Fill incomplete IPv6 tuples to avoid WinError on windows (\965)
lokesh2019

Fixed \932

- Only reschedule types if the send next time changes (\958) bdraco

When the PTR response was seen again, the timer was being canceled
and rescheduled even if the timer was for the same time. While this
did not cause any breakage, it is quite inefficient.

- Cache DNS record and question hashes (\960) bdraco

The hash was being recalculated every time the object was being used
in a set or dict. Since the hashes are effectively immutable, we
only calculate them once now.

- Reduced chance of accidental synchronization of ServiceInfo requests
(\955) bdraco
- Sort aggregated responses to increase chance of name compression
(\954) bdraco

Technically backwards incompatible:

- Send unicast replies on the same socket the query was received
(\952) bdraco

When replying to a QU question, we do not know if the sending host
is reachable from all of the sending sockets. We now avoid this
problem by replying via the receiving socket. This was the existing
behavior when <span class="title-ref">InterfaceChoice.Default</span>
is set.

This change extends the unicast relay behavior to used with
<span class="title-ref">InterfaceChoice.Default</span> to apply when
<span class="title-ref">InterfaceChoice.All</span> or interfaces are
explicitly passed when instantiating a
<span class="title-ref">Zeroconf</span> instance.

Fixes \951

- Fix sending immediate multicast responses (\949) bdraco

- Coalesce aggregated multicast answers (\945) bdraco

When the random delay is shorter than the last scheduled response,
answers are now added to the same outgoing time group.

This reduces traffic when we already know we will be sending a group
of answers inside the random delay window described in
datatracker.ietf.org/doc/html/rfc6762\section-6.3

- Ensure ServiceInfo requests can be answered inside the default
timeout with network protection (\946) bdraco

Adjust the time windows to ensure responses that have triggered the
protection against against excessive packet flooding due to software
bugs or malicious attack described in RFC6762 section 6 can respond
in under 1350ms to ensure ServiceInfo can ask two questions within
the default timeout of 3000ms

- Ensure multicast aggregation sends responses within 620ms (\942)
bdraco

Responses that trigger the protection against against excessive
packet flooding due to software bugs or malicious attack described
in RFC6762 section 6 could cause the multicast aggregation response
to be delayed longer than 620ms (The maximum random delay of 120ms
and 500ms additional for aggregation).

Only responses that trigger the protection are delayed longer than
620ms