TESTrun: Add reject tests for uncovered savefile-parser diagnostics

[anthonyadame]

What

Adds 16 test vectors to the # Savefile-based reject tests follow. section of
testprogs/TESTrun, covering savefile-parser error paths whose diagnostics are not asserted by
any current test — mostly in the pcapng block/option parser.

Each vector is a small (a few dozen bytes) malformed savefile plus the exact diagnostic
pcap_open_offline() must produce for it.

Area	Reject path
classic	truncated file header (two boundary cases)
pcapng	no Interface Description Block
pcapng	packet block before any IDB
pcapng	block length < 12
pcapng	block length not a multiple of 4
pcapng	Section Header Block length below minimum
pcapng	Section Header Block length > BT_SHB_INSANE_MAX
pcapng	truncated read in the Section Header Block
pcapng	IDB if_tsresol bad option length
pcapng	IDB duplicate if_tsresol
pcapng	IDB opt_endofopt with non-zero length
pcapng	IDB if_tsresol decimal resolution too high
pcapng	IDB if_tsresol binary resolution too high
pcapng	IDB if_tsoffset bad option length
pcapng	IDB duplicate if_tsoffset

16 files, 720 bytes total. No source or build-file changes — TEST_DIST already picks up
tests/ via git ls-files.

Why

None of these error paths currently has a test asserting its diagnostic (verified against this
tree: none of the corresponding messages appears anywhere under testprogs/). The fuzz_pcap
target exercises the open path, but it discards the error text and only checks that malformed
input doesn't crash the parser — so a change to any of these diagnostics is not caught by
anything today. These vectors pin the current messages, in the same form as the six existing
savefile reject tests, so future changes to sf-pcap.c / sf-pcapng.c can't silently alter
them.

How the expected strings were produced

The errstr values are not hand-written — each is captured verbatim from the output of a
libpcap build of this tree, so the assertion matches exactly what the library emits. The
generator was first validated against the six existing savefile reject tests and reproduced
all six declared errstr values.

Testing

• All 16 pass via perl testprogs/TESTrun --one reject_<name> (each 0 tests failed / 1 tests passed).
• The six pre-existing savefile reject tests still pass with the new entries added.
• perl -c testprogs/TESTrun is clean.

Verified with a CMake Release build on Ubuntu 24.04 / gcc 13.

[infrastation]

For .pcap files it seems the current error messages are 4 bytes short of how much has actually been read; this problem has not been introduced by this change, but it should be noted that the 23-byte file below indeed looks a boundary case, but the 4-byte file does not. Should this be an empty file instead?

[infrastation]

Thank you for preparing these changes. It seems to me, the new tests would be easier to maintain if each test description was a Perl comment next to the test definition rather than a table in the pull request. The code path could be useful as well, similar to how it is noted for some of the existing tests:

# gen_scode() -> gen_port() -> default case

[anthonyadame]

Thanks — both good points, done in the update.

Each test now carries a comment above it noting the code path it exercises, in the same style as
the existing ones (e.g. # pcap_ng_check_header() -> read_block() -> total_length % 4 != 0, and
# pcap_ng_check_header() -> add_interface() -> process_idb_options() -> case IF_TSRESOL -> saw_tsresol).

On the 4-byte file: you're right, and it turned out to be more than a cosmetic fix. The 4-byte
case and the empty case are actually two different code paths — the 4-byte file gets past the
magic read and fails in pcap_check_header() reading the rest of the header (the "tried to read
24 ... only got 0" message, which as you note is 4 short of what was really read), whereas an
empty file fails earlier, in the magic read in
pcap_fopen_offline_with_tstamp_precision() ("tried to read 4 ... only got 0"). That earlier
path wasn't covered by anything, so I've replaced the 4-byte file with an empty one: it's the
cleaner boundary you're after and it adds the magic-read path. The 23-byte file stays as the
header-rest boundary (one byte short of the full 24).

I've left the "4 bytes short" message itself alone — as you say it predates this change, so it
seemed out of scope for a test-only PR; happy to file it separately if it's worth pinning down.

Full set still passes via testprogs/TESTrun --one reject_<name> (16 new + the 6 existing, no
regression).