Rudimentary NVMe emulation fuzzer

This tries doing a bunch of random operations against an NVMe device and
checks the operations against a limited model of what the results of
those operations should be.

As-is this doesn't catch anything new, but it is sufficient to tickle a
bug in an intermediate state of #953 (which other phd tests did notice
anyway). This fuzzing would probably be best with actual I/O operations
mixed in, and I think that *should* be relatively straightforward to add
from here...

This would probably be best phrased as a `cargo-fuzz` test to at least
get coverage-guided fuzzing. Because of the statefulness of NVMe I
think either way we'd want the model of expected device state and a
pick-actions-then-run execution to further guide `cargo-fuzz` into
useful parts of the device state.

The initial approach at this allowed for device reset and migration at
arbitrary times via a separate thread. When that required synchronizing
the model of device state it was effectively interleaved with "guest"
operations on the device, and in practice admin commands are serialized
by the `NvmeCtrl` state lock anyway. It may be more interesting to
revisit with concurrent I/O operations on submission/completion queues.

Author: iximeow

Cargo.lock

@@ -146,6 +146,7 @@ progenitor-client = "0.10.0"
 proptest = "1.5.0"
 quote = "1.0"
 rand = "0.9.1"
+rand_pcg = "0.9.0"
 reqwest = { version = "0.12.0", default-features = false }
 ring = "0.17"
 ron = "0.8"

Cargo.toml

@@ -52,6 +52,8 @@ tempfile.workspace = true
 slog-term.workspace = true
 slog-async.workspace = true
 rand.workspace = true
+rand_pcg.workspace = true
+ron.workspace = true
 
 [features]
 default = []

lib/propolis/Cargo.toml

@@ -26,6 +26,9 @@ mod cmds;
 mod queue;
 mod requests;
 
+#[cfg(test)]
+mod test;
+
 use bits::*;
 use queue::{CompQueue, Permit, QueueId, SubQueue};