feat(walredo): use posix_spawn by moving close_fds() work to walredo C code

[problame]

The rust stdlib uses the efficient posix_spawn by default.
However, before this PR, pageserver used pre_exec() in our close_fds() ext trait.

This PR moves the work that close_fds() did to the walredo C code.
I verified manually using gdb that we're now forking out the walredo process using posix_spawn.

refs #6565

[jcsp]

LGTM -- if this gets us the performance boost without needing further changes, that's a huge win.

Not sure if we need to ping someone who compiles on a Mac to check if some of the syscall stuff needs #ifdef'ing, but that's secondary to getting this change into staging to see the latency change.

[problame]

I manually tested compilation on my Mac.

[github-actions]

2376 tests run: 2263 passed, 0 failed, 113 skipped (full report)

---

Flaky tests (8)

Postgres 16

• test_gc_cutoff: debug

Postgres 15

• test_statvfs_pressure_min_avail_bytes: debug
• test_gc_cutoff: release, debug
• test_tenant_delete_smoke: release

Postgres 14

• test_gc_cutoff: release
• test_pageserver_restart: release
• test_sharding_service_smoke: release

Code coverage (full report)

• functions: 54.5% (11231 of 20606 functions)
• lines: 81.5% (63280 of 77622 lines)

---

_{The comment gets automatically updated with the latest test results
36f3d87 at 2024-02-01T20:22:59.365Z :recycle:}

[hlinnaka]

This doesn't require seccomp; let's do this even when built without seccomp.

[problame]

I (ab)used the HAVE_SECCOMP as a proxy for that we're on Linux.

Proximity to the seccomp code makes sense IMO because both (and only both) are the essential security building block for walredo.

I'd appreciate if you could provide a follow-up fix that

1. adds a configure check for close_range, so we use the syscall wrapper if it's available in glibc, otherwise fall back to my wrapper & fail to compile if NR_close_range is not defined
2. implements a "status report" walredo command as I suggested on Slack

Also, I'd like to suggest we add additional robustness checks to walredo, e.g., a message where PS can ask a freshly spawned walredo whether it thinks it correctly set up seccomp.

[hlinnaka]

Also, I'd like to suggest we add additional robustness checks to walredo, e.g., a message where PS can ask a freshly spawned walredo whether it thinks it correctly set up seccomp.

Is that the "status report" command you meant?

[hlinnaka]

Created #6580 to track this

[hlinnaka]

To speed this up further, the pageserver could keep a small pool of pre-spawned WAL redo processes. As soon as you use a WAL redo process on a specific tenant/timeline, it must be considered as "tainted" with that tenant, and mustn't be used to replay WAL belonging to any other tenant. But until that first use, there's nothing tenant-specific about them.

[problame]

To speed this up further, the pageserver could keep a small pool of pre-spawned WAL redo processes. As soon as you use a WAL redo process on a specific tenant/timeline, it must be considered as "tainted" with that tenant, and mustn't be used to replay WAL belonging to any other tenant. But until that first use, there's nothing tenant-specific about them.

Yeah, that's what I've been proposing in the slack thread, I'm working on it.
#6581