`bind` may incorrectly create a dual-stack socket on some platforms

UdpSocket::bind and TcpListener::bind can on some platforms incorrectly create a dual-stack socket. It seems very unlikely that these are intended to create dual-stack sockets as the API and documentation make no mention of it. There's also no alternate API that allow for the creation of IPv6 wildcard sockets. This means that if these API were intended to create dual-stack sockets, the standard library would be missing essential IPv6 functionality.

Additional there are good reasons to not have or add an API for dual-stack sockets in the standard library:

• Dual-stack sockets are not portable.
• They are unneccesary as you can use multiple sockets instead.
• They are limited in functionality as you cannot bind to a IPv4 / IPv6 pair.

Users not needing portability and wanting dual-stack sockets, may want to use a 3rd party crate (for example socket2) to create dual-stack sockets.

This bug have some rather bad consequences:

• This means that IPv4 may unexpectedly be accessible over the network which can be a security vulnerability. This is particularly bad if a user tests on a correctly behaving platform, but deploys on another.
• It's not possible to create portable IPv6 wildcard servers with std.
• It's not possible to create portable dual-stack wildcard servers with std.

This affects (at least):

• Linux
• macOS

Not affected:

• Windows
• OpenBSD (does not support dual-stack sockets)

Start with the std networking implementations behind UdpSocket::bind and TcpListener::bind, then compare the platform-specific socket setup on Linux, macOS, Windows, and OpenBSD. Determine the intended wildcard and dual-stack behavior from the API and documentation, and add regression coverage showing that binding follows those documented semantics on affected platforms.