patina_boot: microbench connect_all and expand_device_path

[kat-perez]

Adds criterion microbenchmarks on the benches/ harness:

• connect_all — helpers::connect_all against a synthetic MockBootServices handle topology, parametrized over 1/16/128/512 handles, measuring per-handle connect scaling.
• expand_device_path — helpers::expand_device_path against a synthetic device-path topology with the matching partition placed last, measuring a worst-case full-topology scan over 1/16/128/512 handles.

Both run hardware-free in the dev harness.

Closes #116
Closes #117

[Copilot]

Pull request overview

Adds new Criterion microbenchmarks to the patina_boot crate to characterize scaling behavior of key boot helper routines using fully synthetic, hardware-free mock topologies.

Changes:

• Registers two new bench targets (connect_all, expand_device_path) in Cargo.toml.
• Adds connect_all scaling benchmark over increasing synthetic handle counts.
• Adds expand_device_path worst-case scan benchmark with the matching handle placed last.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
uefi/crates/patina_boot/Cargo.toml	Registers the two new Criterion bench harnesses.
uefi/crates/patina_boot/benches/connect_all.rs	Adds a scaling microbenchmark for helpers::connect_all using MockBootServices.
uefi/crates/patina_boot/benches/expand_device_path.rs	Adds a worst-case topology-scan microbenchmark for helpers::expand_device_path using synthetic device paths.

Suppressed comments (1)

uefi/crates/patina_boot/benches/connect_all.rs:49

• helpers::connect_all does not deduplicate handles by address (it only checks handle-count stabilization), so the explanation of why synthetic handles must have distinct addresses is inaccurate.

    // `connect_all` dedups handles by address (`handle as usize`), so the
    // synthetic handles must have distinct addresses or the topology would
    // collapse to a single connected handle.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

uefi/crates/patina_boot/benches/support/mod.rs:37

• Using raw rdtsc without serialization can under/over-count due to out-of-order execution around the counter reads, which adds noise to microbench results. Add an lfence (or use rdtscp) to serialize the timestamp reads.

    fn end(&self, start: u64) -> u64 {
        // SAFETY: see `start`.
        let now = unsafe { core::arch::x86_64::_rdtsc() };
        now.wrapping_sub(start)
    }

uefi/crates/patina_boot/benches/support/mod.rs:7

• The module docs claim rdtsc cycle counts are frequency-independent and more stable across machines. That’s not guaranteed (e.g., VMs, non-invariant/unsynchronized TSC, core migration), so this wording can mislead when comparing results across hosts.

This issue also appears on line 33 of the same file.

//! [`Cycles`] is a criterion measurement backed by the x86 timestamp counter
//! (`rdtsc`), reporting elapsed reference cycles per iteration instead of
//! wall-clock time. The board acceptance criteria call for cycle counts, which
//! are also frequency-independent and so more stable across machines than
//! wall-time.