fix: one unhealthy drive no longer fails its controller's inventory

[g-carre]

Commits, one per adapter fix: megaraid, ssacli, storcli2 drives, storcli2 volumes.

Fixes ARTESCA-17960 (RD-2154). Stacked on #102: it targets #102's branch, so the diff only shows the fix. Retarget it to main once #102 is merged. It supersedes #91.

Problem

One unhealthy drive could fail the inventory of its whole controller, so every healthy drive on that controller lost its device paths. On the RD-2154 node this blanked all disks in the UI.

Fixes

• megaraid (the RD-2154 case). When the drive of a single-drive RAID0 volume fails, the volume goes offline (OfLn, Exposed to OS: No) and is no longer a block device. getPaths still tried to resolve its paths, failed, and failed LogicalVolumes for the whole controller.
  • A volume reported Exposed to OS: No now gets empty paths without error. Only this explicit value skips resolution, since older storcli versions may not report the field.
  • OfLn is now reported Failed instead of Unknown.
• ssacli (from fix: a single failed drive no longer blanks a controller's device paths #91). A failed or pulled drive whose /dev node is gone made the lsblk lookup fail, which aborted the whole inventory. A lookup failure now marks the device's usage as unknown instead. A free drive whose usage is unknown is reported Unknown, never UnassignedGood, so a drive that may carry data is never offered for a new volume.
• storcli2 drives (from fix: a single failed drive no longer blanks a controller's device paths #91). A Used JBOD drive whose by-id link cannot be resolved is kept with empty paths instead of failing the whole inventory.
• storcli2 volumes. The storcli2 scenario of test: describe hardware scenarios in YAML, play them on the adapters #102 found that the offline volume of a failed drive was still reported with a permanent path built from its NAA Id, although it has no block device. A volume reported Exposed to OS: No now has no paths: neither the permanent path built from its NAA Id, nor a device path from a possibly stale OS drive name.
• Volume creation. It still waits for the new volume: a volume listed before it is exposed to the OS has no paths yet, so it is treated as not settled, and creation keeps rescanning and retrying.
• DESIGN.md. Documents the contract that getter read paths degrade gracefully. The megaraid create/settle path is deliberately stricter.

#91's change for multi-drive megaraid volumes is not carried over, since ARTESCA does not use them.

Tests

• Scenarios. The failed phases of megaraid-disk-failure and storcli2-disk-failure now report their expected tables, so both knownBug blocks are removed. Until they were removed, the tests failed with "the bug looks fixed". All 8 phases pass, for example:

  --- PASS: TestScenarios/megaraid-disk-failure/healthy
  --- PASS: TestScenarios/megaraid-disk-failure/failed
  --- PASS: TestScenarios/megaraid-disk-failure/replaced
  --- PASS: TestScenarios/megaraid-disk-failure/restored
  

• megaraid unit tests, table-driven:
  • getPaths with Exposed to OS set to No (empty paths, no error), Yes, or empty (paths still resolved);
  • the volume status mapping, including OfLn → Failed.
• Volume creation: a new volume first listed as not exposed must be awaited, not returned without paths.
• ssacli: a failing lsblk lookup does not abort the inventory, and a free drive whose device could not be inspected is reported Unknown.
• storcli2, from fix: a single failed drive no longer blanks a controller's device paths #91: an unresolvable JBOD drive, and a degraded storcli2 RAID volume. New: an offline volume not exposed to the OS gets no paths, and permanentPath covers Exposed to OS set to No, Yes and missing.

Delivery

disk-management-agent picks this up once raidmgmt is released and the agent bumps it. scality/disk-management-agent#74 marks its failed phase as a known bug, so it will fail and ask for the marker to be removed at that point.