Fallback F_DUPFD_CLOEXEC to non-atomic ops on AIX on EINVAL

[pgimalac]

Some AIX 7.2 versions don't support F_DUPFD_CLOEXEC, and fcntl returns EINVAL in that case, similarly to older Linux kernels.

This makes tokio fail to initialize on those versions: Failed building the Runtime: Os { code: 22, EINVAL }.

This PR implements a fallback to non-atomically do F_DUPFD then set FD_CLOEXEC when EINVAL is returned on AIX.

A similar mechanism used to exist for Linux (removed by #74606).

[Mark-Simulacrum]

"Some AIX 7.2 versions" -- can you be more specific? Are we missing capturing some version information in the platform support documentation?

[pgimalac]

@Mark-Simulacrum all I can say for now is that AIX 7.2 TL2 doesn't have it but AIX 7.3 TL2 has it.

That's why the PR is still a draft, I wanted to find the TL ("technology level", basically a minor version) which adds support for F_DUPFD_CLOEXEC.
I checked the diff of symbols in the libc between 7.2 TL2 and 7.3 TL2 and this is the only one I found used in rust std.
I'm unavailable next week but after that I'll be able to check each intermediate TL to find when F_DUPFD_CLOEXEC was introduced.

[Gelbpunkt]

AIX 7.2 TL2

Is this even relevant? The first AIX release where Rust is supported in toolbox is 7.2 TL5. That may not be the baseline that Rust is targeting, but I would say it's unreasonable to try to support a lower baseline than what IBM supports.

In my 7.2 TL5 install, F_DUPFD_CLOEXEC exists:

bash-5.3$ oslevel -s
7200-05-09-2446
bash-5.3$ rg F_DUPFD_CLOEXEC /usr/include/
/usr/include/fcntl.h
195:#define  F_DUPFD_CLOEXEC 16          /* Same as DUPFD, but also set