Futex-style API for locking primitives in cooperative threading mode

[TartanLlama]

Adds a futex-style API for cooperative threading mode that serves to unify the ABIs of locking primitives across targets.

The meat of the change is to provide a similar interface to the one used in wasi-threads mode, but that is implemented under the hood by a hash map from futex addresses to cooperative waitlists.

I opted to use an existing MIT-licensed hashmap implementation. We could do more aggressive optimisations, but this should be serviceable for now.

Partially addresses #823: we should make a more public-facing API that is accessible on all targets.

[alexcrichton]

Would it make sense to lift most of the pthread_*.c files from wasi-threads into the common folder for thread implementation (for all targets, not just wasi-threads/wasip3). My thinking is then the per-implementation files might be "just" thread management itself (create/join/etc) and futex.

Otherwise though this looks good to me!

[alexcrichton]

Is the thinking here that something like ENOMEM would surface as a spurious wakeup? (not that there's anything else that can be done)

[TartanLlama]

Would it make sense to lift most of the pthread_*.c files from wasi-threads into the common folder for thread implementation (for all targets, not just wasi-threads/wasip3). My thinking is then the per-implementation files might be "just" thread management itself (create/join/etc) and futex.

That would be ideal, but the wasi-threads implementations have a bunch of nuances that I struggle to piece together just from reading the (essentially undocumented) code. It's possible that it all "just works" with this new futex implementation slotted in, but perhaps we can try that as a future PR.

[alexcrichton]

My hunch is that the primitives there are mostly upstream musl itself, which I agree is virtually entirely undocumented and pretty difficult to read... My hope is that by the virtue of basically being upstream primitives though we probably don't have to worry much about them.

[alexcrichton]

Was there anything else you wanted to tweak before landing as well? Otherwise happy to merge as-is

[TartanLlama]

I think we can merge this, then I'll play around with deduplicating the primitives with the wasi-threads implementations.

[TartanLlama]

For exposing this to, e.g., the Rust stdlib I guess we should invent __wasilibc_futex_{wait,wake} or something and implement that for all targets. Maybe have some enum to define an options argument that can encode WASILIBC_FUTEX_YIELD or similar

[alexcrichton]

Agreed yeah, we'd probably add that to the preexisting wasi/libc.h and then document is as a "intended to be stable" API and such