Add ability to specify backlog size for `TcpListener` and `UnixListener`

[BartMassey]

In socket-style network interfaces, the server side typically requests a "backlog" from the operating system. This controls how many requests the OS is willing to buffer before failing or ignoring new requests.

The backlogs used by std::net::TcpListener::bind, std::os::unix::net::UnixListener::bind and the nightly std::os::unix::net::UnixListener::bind_addr are currently hardwired to 128. This is a reasonable default, but there are situations where one might want to set a larger or smaller number. Also, that 128 default should probably be a publicly-exposed constant.

To address these issues I have posted a PR that provides the following new APIs:

• std::net::TcpListener::DEFAULT_BACKLOG
• std::net::TcpListener::bind_with_backlog
• std::os::unix::net::UnixListener::DEFAULT_BACKLOG
• std::os::unix::net::UnixListener::bind_with_backlog
• std::os::unix::net::UnixListener::bind_addr_with_backlog

[NotWearingPants]

#55614

[BartMassey]

I have talked with @joshtriplett about the stuff that blocked my last attempt at a PR, and am going to try again in the next couple of weeks. Sorry for leaving this sitting for so long.

[rustafariandev]

Any updates on this?

[BartMassey]

I am sad to report that there is not. I really feel bad, but there it is.

The fundamental problem is that std::net::TcpListener::bind is supposed to be part of std for all platforms, including those that do not support adjusting the number of listeners, or don't have the concept of a backlog at all. The suggestion has been to ignore the backlog parameter on those platforms, as well as ignoring it when it is out of bounds for the platform. However, that seems to me to be a recipe for surprises: if I ask for a particular backlog I expect to either get that backlog or have the call fail. But… the problem with having the call fail is that I don't have access to a bunch of the weirder platforms and the conditions under which the backlog is legal are not well documented.

So I got stuck and never really got back to it.

You can take a look at the patch linked above for how far I got. I can try to have some more discussion with folks and find a student for this.

[Mark-Simulacrum]

Closing as a duplicate of #55614, I don't think we need two issues for this.