Parse SR-4731 Issue 1 Map blocks: size BlockInfo from block_size, optional block prefixes

[markw362]

Summary

Makes the parser accept SR-4731 files whose Map block follows the Issue 1 conventions, without changing behaviour for the Issue 2 files the test suite already covers.

Two related changes in src/parser.rs:

1. Size the Map's BlockInfo table from block_size, not block_count.
   block_count is not consistent across vendors and issues: Issue 2 (rev ≥ 2.50) files count the Map block itself, Issue 1 (rev 2.00) files count only the blocks that follow, and some Issue 1 vendor files use the Issue 2 convention anyway. The current code reads block_count - 1 entries, which under-reads by one on files that use the Issue 1 convention; the unread entry (usually Cksum) is then encountered where GenParams is expected and parsing fails. block_size, on the other hand, has been the total byte length of the Map block in every file I have seen, so the table is now consumed until that length is exhausted (stopping at trailing zero padding). block_count is still parsed and retained verbatim in MapBlock for fidelity.

2. Treat the per-block BlockName\0 prefix as optional.
   Issue 2 prefixes each data block with the same identifier the Map already carries; Issue 1 files from older or simpler equipment omit it. maybe_block_header consumes the prefix when present and no-ops when absent, so one code path handles both. The following fields are still parsed strictly, so a genuinely misplaced block still fails.

Motivation

Six EXFO FTB-series rev 2.00 traces from a production fibre plant fail to parse on 1.1.1 with

Error { input: [67, 107, 115, 117, 109, 0, ...], code: ... }   // "Cksum\0"

Their Map has block_count = 7 and seven BlockInfo entries after the Map (GenParams, SupParams, FxdParams, KeyEvents, DataPts, a proprietary EXFO block, Cksum) inside a block_size of 135, i.e. the Issue 1 convention. With this change all six parse, and every fixture in data/ produces identical output before and after.

I can't redistribute those traces, so the regression test synthesises the same shape from the existing example2-exfo-maxtester730c.sor fixture by decrementing block_count (the BlockInfo table and block_size are untouched, which is exactly what the failing files look like). The test fails on main and passes with this change.

Testing

• cargo test: 23 passed (22 existing + new test_map_block_count_excluding_map_block).
• Parsed all seven data/ fixtures plus a Viavi/JDSU rev 2.50 file with 15 blocks before and after; identical MapBlock, key-event and data-point output.
• Parsed the six previously failing EXFO rev 2.00 files: all succeed, event counts match the instrument's own report.

Happy to adjust naming or split the two changes into separate commits if you'd prefer to take only the Map sizing.

[Kreijstal]

good good