GetWwnByScsiInq: handle sg_inq v2.3x (sg3_utils 1.48+) output format change

[carterpewpew]

Problem

sg3_utils 1.48+ changed sg_inq -p 0x83 to output raw hex bytes instead of the decoded Device Identification VPD page. This breaks GetWwnByScsiInq the driver extracts an empty WWN, NodeStageVolume fails, and volumes never mount.

Reproduced on:

• SUSE Linux Micro 6.1 (sg_inq v2.32, sg3_utils 1.48)
• Harvester 1.7.1
• Debian Trixie (sg_inq v2.48, sg3_utils 1.48)
• OKD 4.20 / CentOS 10

The actual output on affected systems for sg_inq -p 0x83 /dev/dm-X:

VPD INQUIRY, page code=0x83:
00 00 83 00 24 01 03 00 10 60 05 07 68 10 81 05 ab
10 58 00 00 00 00 00 00 37 01 94 00 04 00 00 0e 86
20 01 95 00 04 00 00 00 11

The driver expected the decoded text output with [0x<wwn>] brackets, which no longer appears.

Fix

• Try sg_inq -i first. The -i/--id flag produces the decoded Device Identification output (with bracketed WWN) on all sg_inq versions — it has existed since at least sg3_utils 1.42.
• Fall back to sg_inq -p 0x83 if -i fails to execute or its output is unparseable.
• Add a secondary 0x<hex> regex (without brackets) on the WWN line as defense for any future format variants.
• Surface execution errors properly in mixed failure scenarios (e.g. -i output unparseable + -p 0x83 times out) instead of returning a misleading MultipathDeviceNotFoundForVolumeError.
• Extract parsing into getWwnFromScsiInqOutput() for testability.

Tests

• sg_inq -i success (bracketed WWN) — NAA6 and EUI-64
• sg_inq -i raw hex output (no brackets) — NAA6 and EUI-64
• -i output unparseable → fallback to -p 0x83 succeeds
• -i execution failure → -p 0x83 succeeds
• Both commands fail to execute → combined error
• Empty output from both → MultipathDeviceNotFoundForVolumeError
• Mixed parse + execution failure → surfaces execution error, not device-not-found

Backwards compatibility

On older sg3_utils (< 1.48), sg_inq -i produces the same decoded output that -p 0x83 used to. The driver will parse it via the existing bracket regex on the first attempt. The -p 0x83 fallback is never reached in the happy path no behavior change for working environments.

Fixes #850
Fixes #824