fix delays when sending initial probe packets

[marten-seemann]

From https://datatracker.ietf.org/doc/html/rfc6762#section-8.1:

When ready to send its Multicast DNS probe packet(s) the host should
first wait for a short random delay time, uniformly distributed in
the range 0-250 ms. This random delay is to guard against the case
where several devices are powered on simultaneously, or several
devices are connected to an Ethernet hub, which is then powered on,
or some other external event happens that might cause a group of
hosts to all send synchronized probes.

250 ms after the first query, the host should send a second; then,
250 ms after that, a third. If, by 250 ms after the third probe, no
conflicting Multicast DNS responses have been received, the host may
move to the next step, announcing.

Note that we don't properly distinguish between probing and announcing, and we don't do any conflict detection at all. This PR should still at least bring us closer to what the spec is saying, and hopefully help us resolve libp2p/go-libp2p#1167.

[marten-seemann]

Taking the approval for #16 as an approval for this PR as well.