physicaldrivegetter: add storcli2 physical drive getter

[ezekiel-alexrod]

What

Implements ports.PhysicalDrivesGetter for storcli2 / perccli2 (physicaldrivegetter/storcli2.go), mirroring the ssacli getter and the megaraid v1 physical-drive parsing. Also fixes the storcli2/perccli2 command runners to surface in-JSON errors when the binary exits non-zero, and aligns the stale storcli2 package docs with that corrected exit-code contract.

How

• PhysicalDrives(ctrl) → a single /cN/eall/sall show all (its Drives List already carries each drive's detailed information).
• PhysicalDrive(meta) → /cN/eX/sY show all (or /cN/sY without an enclosure, as in megaraid v1), with a not-found guard on an empty list.
• Each Drives List entry maps to a PhysicalDrive: vendor/serial/WWN (0x-prefixed as in megaraid v1) from Drive Detailed Information, model and type (Med) from Drive Information, size via utils.ConvertSizeBytes, status from the State/Status pair, and Reason carrying the raw status (as in the ssacli getter).
• One implementation serves both binaries via an injected commandrunner.CommandRunner. Section structs live in the getter file and consume the shared storcli2.Decode + utils.UnmarshalToSlice.

State/Status mapping

The mapping follows the drive-state legend printed by the binary, verified on a live MegaRAID 9660-16i. Two storcli2 specifics drive the design:

• storcli2 has no Failed drive state (storcli1 had one): failure is reported in Status. A Failed, Offline or Missing status therefore takes precedence over any state, so a non-functioning drive is never reported as in use — or worse, available for LV creation.
• Every base state comes in suffixed variants (Shld shielded diagnostics, Sntz sanitize, Dgrd degraded — e.g. ConfDgrd, JBODSntz, UConfShld), so states are matched by family rather than exactly. The lone exception is Shld (“JBOD Shielded”), which belongs to the JBOD family without the prefix.

Resulting map: Conf* / JBOD* / Shld / GHS* / DHS* → used; UConf* → unassigned good, unless the status is Bad or the state is UConfUnsp (unsupported) → unassigned bad; Failed / Offline / Missing status → failed; anything else (Unusbl, Various, …) → unknown with the raw status in Reason.

Device paths are computed only for healthy JBOD drives (ComputePaths reads the real filesystem): a dead JBOD drive whose device node is gone must not fail the whole inventory. A synthetic-payload test pins this guard at the entity level (the captured fixtures contain no JBOD drive).

Command runner fix

storcli2/perccli2 do not use the exit code as a reliable success signal: some failures (invalid drive) exit non-zero while still writing their JSON error payload to stdout, others (invalid controller/VD) exit zero. cmd.Output() turned the former into a bare exit status N and discarded the payload. The runners now return stdout as-is on a non-zero exit with a payload, letting storcli2.Decode surface the in-JSON error ("No PD found."); a non-zero exit with no stdout stays a hard error. The storcli2 package docs (envelope.go, decode.go), which still claimed the CLI "exits 0 even on failure", are reworded accordingly.

Tests

Table-driven storcli2_test.go, reusing the testify mock runner and testdata/storcli2/ fixtures (real server captures: 24-drive inventory, single drives, UConf/Good, invalid-drive failure payload). Cases: full inventory, single drive (configured / unconfigured / not found), empty-list guard, JBOD entity-level mapping with the ComputePaths guard, and unit tables for the State/Status mapping (families, Failed/Offline/Missing precedence, hot spares, unsupported), JBOD family detection, disk type, WWN formatting and selector building. Runner tests cover both non-zero-exit paths. The full flow was also validated end-to-end against the live 9660-16i captures.

UG v1.1 alignment (second commit)

Cross-checking against the StorCLI2 User Guide v1.1 surfaced three gaps, fixed in physicaldrivegetter: align storcli2 typing and statuses with UG v1.1:

• NVMe typing: storcli2 reports an NVMe drive with Med=SSD and the transport in Intf (the guide's sample shows Intf NVMe, Med SSD), so deriving the type from Med alone could never yield NVMe. The type now checks Intf first.
• Unusable status: a documented drive status; an unconfigured drive with it was reported unassigned-good (selectable for VD creation). It now maps to unassigned-bad, like Bad.
• Empty inventory: per the guide, showing a nonexistent object reports success, so an absent Drives List section is an empty inventory, not an error (mirroring the logical-volume getter's zero-VD contract). Replace (copyback) is also pinned as in-use in the status table.