Write deadlock fixes and overall reliability improvements

[requilence]

1. introduce writeTimeout for both server and clients
   I have noticed that in some scenarios socket write(like here) can hang for indefinite time.
   At least it reproducible in the latest MacOS release(13.2) when writing on some standard network interfaces.
   In this case it blocks all the further writes to other interface and deadlock Shutdown
   This PR introduce WriteTimeout and ClientWriteTimeout option with default of 10 sec. It seems to be much more than ok. In my case it either writes under 10ms or hangs indefinitely

Overall if it will be timeout'ed we still have 3 tries in the probe

2. Introduce the proxy struct NetInterface that alongside the net.Interface stores the bitmask flags MulticastJoined and MessageSent separately for IPv6 and IPv4.
   The reason behind this is that multicastResponse call without interface specified works in a way it iterates through all interface to send the message. This makes unregister tries to connect to interfaces that can be failed to join multicast group or send the announce - which is make no sense

On macOS I faced situations where some interface can join IPv6 multicast but can't join IPv4 multicast, or can announce on IPv6 but always hang(timeout) during announceText.

So multicastResponse now has an optional arguments to pass required flags

3. Add ServerSelectIPTraffic option similar to client's SelectIPTraffic option to disable IPv6 or IPv4 multicast.
   This seems pretty useful to have, because you have no other way to control it, and IPv6 multicast may be more tricky to support

[MarcoPolo]

Do these issues also show up in the https://github.com/grandcat/zeroconf library that this fork is based on? If so I think it work benefit more folks to open the PR there.

[MarcoPolo]

Also, could it be possible to add some tests here as well?

[MarcoPolo]

friendly ping @requilence

[p-shahi]

Hi @requilence , go-libp2p maintainers are not prioritizing reviewing this atm. It would be great if you can split this PR into two: one for bugfixes and one for the reliability improvements. We can prioritize looking at the bugfix