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

[g-carre]

Overview

This PR reproduces ARTESCA-17960 from real RAID utility output, without hardware. For each controller utility it records what raidmgmt reports today: MegaRAID and storcli2 show the bug, which is marked as known, and ssacli does not. Each commit covers one controller utility.

The fix, #107, is stacked on this PR so it can be reviewed separately. Both are meant to merge together.

Details

Adds scenario/, a test kit that replays hardware events (a drive fails, is replaced, gets a new volume) on real RAID controller output, and checks what raidmgmt reports for each drive. No hardware is needed. The scenarios are written in Gherkin and run with godog.

The first scenarios reproduce ARTESCA-17960 (RD-2154): on MegaRAID and storcli2, one failed drive blanks the device paths of every drive on the controller. This PR only adds the tests and records the bug as a known bug; #107 removes the known bug steps.

What a scenario looks like

@megaraid
Feature: MegaRAID disk failure and replacement

  Background:
    Given the controller captured as "megaraid9560-4hdd"

  Scenario: A failed drive does not take the paths of the others
    When drive 251:3 fails
    Then the drives are reported as:
      | slot  | status | serial               | devicePath | permanentPath                                          |
      | 251:1 | Used   | SIMD0001000000000000 | /dev/sdl   | /dev/disk/by-id/wwn-0x600062b2000000000000000000000239 |
      | 251:3 | Failed | SIMD0003             |            |                                                        |
      ...
    But known bug ARTESCA-17960 reports instead:
      | slot  | status | serial               | devicePath | permanentPath |
      | 251:1 | Used   | SIMD0001000000000000 |            |               |
      ...

• The Background names a capture: real output of a lab controller with all drives healthy, cut to 4 drives, with fake serials and WWNs.
• The steps are the same for every controller. Each simulator applies them the way its controller shows them.
• Each Scenario is self-contained: its prerequisites are Given steps, and it runs as its own subtest.
• A But known bug <ticket> reports instead: table after a Then gives what is reported today. The step passes while that table is reported. It fails when the expected table is reported ("the bug looks fixed, remove its known bug step") and when neither is (the behaviour changed). A failure prints the reported table, ready to paste.

Each controller family has 4 scenarios: all drives healthy, one drive failed, the failed drive replaced, and a new volume on the replacement. The failed-drive scenario carries the known bug on MegaRAID and storcli2. ssacli passes.

Commits

One commit per adapter, each passing tests and lint on its own:

1. Framework and MegaRAID. Harness, steps, the MegaRAID simulator and its capture, the CI changes.
2. storcli2. Simulator, capture and feature.
3. HPE Smart Array (ssacli). Simulator, capture and feature.

How to review

Most of the diff is captures: JSON and text under */captures/. You can skim them. Their serials and WWNs are fake.

Suggested order:

1. scenario/features/*.feature. These are the specification. Check that the expected tables are what raidmgmt should report after each event.
2. scenario/README.md. Steps, how known bugs work, how to add a scenario or a controller.
3. scenario/scenario.go, steps.go, report.go. The harness:
   • scenario.go: parsing and comparing tables. It rejects a wrong header, an empty table and duplicate slots.
   • steps.go: the step definitions. Undefined steps fail (strict mode). A known bug step is tied to the Then right before it.
   • report.go: turns the adapter's drives and volumes into rows.
4. scenario/steps_internal_test.go and scenario/testdata/. They check that the harness fails when it should: a differing table, a missing drive, a fixed or changed known bug, a misplaced known bug, an undefined step, a bad table.
5. The simulators: megaraidsim, storcli2sim, ssaclisim. Each answers the CLI commands of the raidmgmt adapter from the capture, with the events applied. The package docs say how each controller shows each event. For example, MegaRAID cuts a failed drive's serial to 8 characters, and ssacli moves a replaced drive to Unassigned. */adapter_test.go plays the features through the real raidmgmt adapter.
6. CI and Makefile. scenario/ is a nested Go module. Module detection now finds every go.mod, tests run in each module's directory, and make tests runs both modules (used by the release workflow).

Points to look at

• Nested module. scenario/ has its own go.mod, with a replace pointing to the repository root. This keeps godog out of raidmgmt's own dependencies. Its tests use testify, like the root module.
• Simulator fidelity. No controller output was captured while a drive was failed. The failed and replaced states follow what storcli showed on the RD-2154 node. Each package doc says so.
• New events. A state that the current steps cannot produce needs a new step in steps.go and its handling in every simulator.

Running locally

cd scenario && go test ./...

Refs: ARTESCA-17960