Add address_space_id parameter to futex wait/wake for multi-process support

[wdcui]

Summary

• Add address_space_id: u64 discriminator to FutexEntry, bucket hashing, wait(), and wake() to prevent false aliasing between processes with overlapping virtual address ranges.
• Userland callers (single address space) pass 0.
• Update all shim callers and futex tests.

Split from #743.

[github-actions]

🤖 SemverChecks 🤖 ⚠️ Potential breaking API changes detected ⚠️

Click for details

--- failure method_parameter_count_changed: pub method parameter count changed ---

Description:
A publicly-visible method now takes a different number of parameters, not counting the receiver (self) parameter.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#fn-change-arity
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.47.0/src/lints/method_parameter_count_changed.ron

Failed in:
  litebox::sync::futex::FutexManager::wait takes 4 parameters in /home/runner/work/litebox/litebox/target/semver-checks/git-main/3f147ef888356c93d58d41289364c3f400dffaec/litebox/src/sync/futex.rs:83, but now takes 5 parameters in /home/runner/work/litebox/litebox/litebox/src/sync/futex.rs:98
  litebox::sync::futex::FutexManager::wake takes 3 parameters in /home/runner/work/litebox/litebox/target/semver-checks/git-main/3f147ef888356c93d58d41289364c3f400dffaec/litebox/src/sync/futex.rs:135, but now takes 4 parameters in /home/runner/work/litebox/litebox/litebox/src/sync/futex.rs:155

[jaybosamiya-ms]

Private or not is more of a performance optimization for Linux at least, I am not entirely convinced that we even need the "same virtual address in different address spaces": what is the concrete scenario this comes up, and not having this address_space_id leads to incorrect behavior?

Furthermore, if we need to have an address_space_id somehow, then I am not so sure of the specific types/design used here. Specifically, u64 + opaque kinda leads to a design where it is easy to get things wrong. If we really need it, we probably need a more fleshed out process abstraction for LiteBox, and then this should probably be referring to address spaces from that abstraction. For now, this seems like overfitting some particular design, but the design itself is unclear.

A couple more concrete questions (if we are going this route): is address_space_id meant to be one value assigned from each process? How is the opaque value meant to be picked up (i.e., where is it meant to come from)? Any particular reason we are not using a process identifier instead of an address_space_id? Additionally, in terms of the parameter space, do we expect 64-bits of such identifiers to be used? What is the guidance for single-process shims? etc.

Oh, and (if we are going this exact route) each of the places in the shim where 0s have been added in, those should be documented as places we intend to change once the other bits of this are figured out. A proper abstraction would not have this issue I think.