add pidfd_open(2) and pidfd_send_signal(2)

[CobaltCause]

What does this PR do

It adds pidfd_open(2) and pidfd_send_signal(2). I personally don't have an immediate need for pidfd_getfd(2) so it's not included in this PR. It's particularly important to me that the pidfd_open(2) implementation is async-signal-safe, so that it can be used between fork and exec to achieve race-free PIDFD acquisition without violating any libc's invariants; see the conversation at rust-lang/rust#89522 (comment) for details on that topic.

See #1868 for prior art; review comments there have been addressed here.

Checklist:

• I have read CONTRIBUTING.md
• I have written necessary tests and rustdoc comments
• A change log has been added if this PR modifies nix's API

[CobaltCause]

CI / cross (arm-unknown-linux-gnueabi) (pull_request) and CI / cross (armv7-unknown-linux-gnueabihf) (pull_request) are failing because they don't have the syscalls, don't know what to do about that. CI / cross (powerpc64le-unknown-linux-gnu) (pull_request) seems to be stuck in the test for pidfd_send_signal(2), don't know what to do about that either¹. CI / redox (pull_request) and FreeBSD 14 amd64 & i686 seem to be failing for unrelated reasons?

Footnotes

1. Actually, maybe it's stuck because the parent process experienced a race with the child's PID... ↩

[CobaltCause]

Changing the test to eliminate any potential races actually made it worse, CI / cross (arm-unknown-linux-gnueabi) (pull_request) and CI / cross (armv7-unknown-linux-gnueabihf) (pull_request) became stuck in addition to the one mentioned before. I don't seem to be able to manually cancel the runners and there doesn't seem to be any timeout (the previous attempt ran for about five hours before I pushed again), so I'm just going to add a commit to disable the pidfd_send_signal(2) test for now.

[CobaltCause]

The common problem between all three checks that were getting stuck is that all of them returned ENOSYS for the PIDFD syscalls. The second round of deadlocks were probably from recvmsg since the corresponding sendmsg would never have been reached, but the cause of the first deadlock is still beyond me. I've reverted back to the simpler test and handled ENOSYS such that the tests explicitly pass in that case, and now the deadlocks are gone and the new tests pass as expected. But now CI / macos-aarch64 (pull_request) is also failing though this seems unrelated.

[CobaltCause]

Hmm, pushed again and now CI / macos-aarch64 (pull_request) is passing, maybe it's just flaky?