Allow users to remap FDs before container start

[aidanhs]

Note: this is not ready for merge (no tests, no exposure via cli, not signed off) but I've been carrying/using the branch for a while and thought I'd make a PR in case it's useful to anyone/see if there's any desire to get it into a mergeable state. It's built on top of #2892 and #2893 - to see the actual changes you'll want to look at aidanhs/youki@aphs-remap-fds~2...aidanhs:youki:aphs-remap-fds. The first commit improves FD discipline by passing fewer down to the intermediate process, the second implements remap fds.

The primary purpose of this PR is to allow programs that are not disciplined with their FDs to invoke containers and pass down FDs in a controlled way (i.e. without leaking any).

For example, if I have let f = fs::File::open(...).unwrap() - let's say the FD is 25 (and may vary, depending on what other file operations I'm performing in the program/other threads). How do I pass this to my program? nsjail has an argument for this (--pass-fd) but it's a lot harder if you want to use youki as a library:

• You cannot use preserve_fds = 23 as this will pass all file descriptors up to 25
• You cannot relocate fd 25 to 3 via dup and use perserve_fds = 1 because you don't know what's using fd 3 - you'd need to refactor the whole program to be disciplined about FD usage (which may not even be possible if threads are involved).
• The correct way today (once Fix --preserve-fds, eliminate stray FD being passed into container #2893 is merged) is to fork, relocate fd 25 to 3 and use preserve_fds - but now you have an extra process you need to communicate with and manage.

remap_fds solves this problem by acting as a more general --pass-fd:

• if you pass (25, 25) the fd will be unmarked as cloexec and passed down to the container
• if you pass (25, 3) the fd will be remapped by youki at the last moment, when it is safe to do so, and then passed down

Unfortunately this will probably not work well in combination with seccomp - because remapping has to happen so late, seccomp enforcement will already be in place. There is a way to fix this that I have noted in the code, but I think it's quite difficult.

[YJDoc2]

Hey, I have made this draft + added wontfix label just to signify that there is nothing immediate too be done on this (from reviewer side). This is not really a "wontfix" , if you do get this ready for a merge, you can mark this ready to review, after which we can do the normal review process + remove the label.