Move futex locks to sys_common

[joboet]

These implementations are also used on WASM and Hermit, so it does not really make sense to keep them in sys::unix, especially considering that the current path-based imports have already lead to breakage (#99800). Moving them to sys_common mirrors the organization of the thread parking implementations, and provides a good place for future generic lock implementations (see #93740) to go.

r? @m-ou-se

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[the8472]

This probably isn't the right place either because sys_common shouldn't contain platform cfg() stuff even though tidy currently doesn't complain about it either.

I was going to suggest moving it to sys::common instead but its mod.rs does say

rust/library/std/src/sys/common/mod.rs

Lines 1 to 5 in cd12888

	// This module contains code that is shared between all platforms, mostly utility or fallback code.
	// This explicitly does not include code that is shared between only a few platforms,
	// such as when reusing an implementation from `unix` or `unsupported`.
	// In those cases the desired code should be included directly using the #[path] attribute,
	// not moved to this module.

So the #[path] seems to be the approved way already.

[joboet]

Since this concerns other code like the thread parker and one-time initialization as well, I suggest we discuss this in #84187 (the tracking issue for that guideline).

[workingjubilee]

I don't want to devalue the contributions of anyone who has worked on libstd, but this mostly seems like it was one person's idea 2 years ago about what would be a good organization of stuff, tbh. Since then we've sprouted a lot more small niche mostly-tier-3 targets that are mostly just repeats of Linux or other POSIX platforms, yet with enough annoying variations that they induce quite a lot of configuration around that. I think we should revisit those guidelines heavily.

[bors]

☔ The latest upstream changes (presumably #106228) made this pull request unmergeable. Please resolve the merge conflicts.

[joboet]

This PR is superseded by #117276, closing.