test: describe hardware scenarios in YAML, play them on the adapters

[g-carre]

Refs ARTESCA-17960 / RD-2154. Used by scality/disk-management-agent#74.

Adds hardware scenarios written in YAML. Each scenario takes a real controller capture, then changes drives and volumes phase by phase, and gives the table of disks expected in each phase. The scenarios are played through the raidmgmt adapters here, and through the agent in #74.

The scenario: scenario/scenarios/megaraid-disk-failure.yaml

- name: failed
  description: |
    251:3 fails. Its RAID0 volume goes offline and is no longer a block
    device. The other drives must keep their paths.
  knownBug: ARTESCA-17960
  changes:
    drives:
      "251:3": {state: Failed, serial: SIMD0003}
    volumes:
      "237": {state: OfLn, exposed: false}
  expect: |
    slot    status  serial                devicePath  permanentPath
    251:1   Used    SIMD0001000000000000  /dev/sdl    /dev/disk/by-id/wwn-0x600062b2…0239
    251:3   Failed  SIMD0003              -           -
    ...

The phases are healthy, then failed (251:3 fails and its RAID0 goes offline), then replaced (a new drive, UGood), then restored (a new RAID0 volume). The capture is real storcli output of the RD-2154 lab node, kept to its first 4 drives (251:1-4) to keep the tables short, with serials, WWNs and controller identifiers replaced by fake ones. The failure is derived from what that node showed when 251:3 failed, as explained in the scenario description.

Known bugs are expected failures

A phase with knownBug must differ from its table. The test passes and logs the differences:

expected failure, ARTESCA-17960:
    251:1 devicePath: got -, want /dev/sdl
    ... (the healthy drives lose their paths)
    LogicalVolumes: reported but not expected: failed to get logical volumes: failed to get logical
    volume 237: failed to get paths: failed to compute paths from physical drive: failed to compute permanent path

Once the phase matches its table, the test fails with the bug looks fixed, remove its knownBug line, so the fix PR has to update the scenario. This is also the result on the #91 branch: #91 only handles volumes with several drives, and VD 237 is a single-drive RAID0.

Layout: a separate module, github.com/scality/raidmgmt/scenario

• scenarios/*.yaml: the scenarios.
• scenario: loads them and compares the reported disks with a table, including the known-bug rule.
• megaraidsim: answers storcli64 commands from a capture with the changes of a phase applied, and shows the /dev/disk/by-id links of the exposed volumes.
• megaraidsim/adapter_test.go: plays every MegaRAID scenario through this repository's megaraid adapter, thanks to a replace ../.

It is a separate module so that consumers can play the scenarios without changing the raidmgmt version they test. The agent stays on v0.16.0, and even the 4.3 agent (raidmgmt v0.14.0) could use it. Adding a controller means a capture plus a backend like megaraidsim; adding a scenario on an existing capture is just a YAML file. See scenario/README.md.

CI

• The module list now includes nested modules, and tests run in each module's directory.
• The scenarios run in the normal tests job. There is no build tag and no extra job.
• make tests also runs them.