Some systems set an artificially low soft limit on open file count,
for compatibility with code that uses select and its hard-coded
maximum file descriptor (limited by the size of fd_set).

Go does not use select, so it should not be subject to these limits.
On some systems the limit is 256, which is very easy to run into, even
in simple programs like gofmt when they parallelize walking a file tree.

After a long discussion on go.dev/issue/46279, we decided the best
approach was for Go to raise the limit unconditionally for itself, and
then leave old software to set the limit back as needed. Code that
really wants Go to leave the limit alone can set the hard limit, which
Go of course has no choice but to respect.

Take 2, after CL 392415 was rolled back for macOS and OpenBSD failures.
The macOS failures should be handled by the new call to sysctl("kern.maxfilesperproc"),
and the OpenBSD failures are handled by skipping the test (and filing #51713).

Fixes #46279.

Change-Id: I45c81b94590b447b483018a05ae980b8f02dc5de
Reviewed-on: https://go-review.googlesource.com/c/go/+/393354
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>

For #46279
For #51713

Change-Id: I444f309999bf5576449a46a9808b23cf6537e7dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/394094
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>