port Miri to edition 2021
`cargo fix --edition` didn't change anything for either of these crates, so this looks like a very simple port. And then we can remove a bunch of annoying imports. :)
I thought this also unlocks the named format string stuff, but it seems that works on all editions except for that problem around `panic!`. Whatever. ;)
For variadic functions, accept arbitrary trailing arguments
However, make sure that if we use argument N we check the size of all arguments before that, because otherwise this might not work properly depending on how varargs are implemented. This caught bugs in our futex tests. ;)
I couldn't find a good way to systematically ensure this, so it is just something we have to be on the look for during review. (This generally applies also for fixed-arg shims: we should check the size of each parameter.)
Also treat prctl like a variadic function, Cc `@saethlin.`
Add support for FUTEX_{WAIT,WAKE}_BITSET
FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET are extensions of FUTEX_WAIT and FUTEX_WAKE that allow tagging each waiting thread with up to 32 'labels', and then only wake up threads that match certain labels. The non-bitset operations behave like their bitset was fully set (u32::MAX), meaning that they'll wait for anything, and wake up anything.
The only other difference is that FUTEX_WAIT_BITSET uses an absolute timeout instead of an relative timeout like FUTEX_WAIT.
Often, FUTEX_WAIT_BITSET is used not for its bitset functionality, but only for its absolute timeout functionality. It is then used with a bitset of u32::MAX.
~~This adds support for only that use case to Miri, as that's all `std` currently needs. Any other bitset is still unsupported.~~
Update: This adds full support for both these syscalls.
make strict-provenance imply check-number-validity
I feel like Miri not catching [this example](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) with strict provenance checking enabled is surprising.
OTOH, Miri suddenly complaining about uninit data in integers with `-Zmiri-strict-provenance` also might be surprising. Which one is more surprising? I don't know. We *could* go out of our way and have a mode where uninit integers are okay but provenance is not, but I am not sure if that is truly worth it. It'd be quite annoying to implement.
