fix(protocols): the default engine accepts an IPv6 Jumbo Payload option of 65535 octets or less, against RFC 2675

Question, found while fixing #1671 (PR #1686): should the default engine accept an IPv6 Jumbo Payload option whose Jumbo Payload Length is 65535 or less?

RFC 2675 §3 says a jumbogram must have a Payload Length of 0 and a Jumbo Payload Length greater than 65535, and that a receiver must treat any other combination as an error. On main (7aeeaf804, 3.11, tshark 4.6.9), for TCP behind such an option on IPV6 or Ethernet:

the default engine traces it, as do dpkt and scapy (1);
tshark flags "Jumbo Payload option missing" as malformed and dissects no TCP, so pyshark traces 0.
A genuine jumbogram of 70,028 octets agrees on every engine.

Options:

Keep accepting it. pyshark then needs to read these frames from their octets.
Reject it in the default engine, following RFC 2675 and the "each concrete class checks its own header" ruling on fix(protocols): IPv6.read accepts a header whose Version is not 6 #1680. dpkt and scapy then need to stop there too.

i say option 2. follow the RFC's documentation.

Recorded: option 2, following RFC 2675 §3. The default engine treats a Jumbo Payload option whose length is 65535 or less, or a jumbogram whose IPv6 Payload Length is not 0, as an error, and dpkt and scapy stop at the same place. tshark and pyshark already do. Retitled as a fix. A worker is on it, in one PR for the default engine and the dpkt and scapy adapters. #1680, which edits the same adapters, follows it.

And actually i think 3p engines do not have to match the default engine's behaviour 1:1. we just use them at best efforts, meaning, extraction engine harness plus toolkit functions for data model conversion (to match reassembly/traceflow's needs)

Recorded: third-party engines (dpkt, scapy, pyshark, pypcapfile, ...) are best effort. They provide the extraction harness, plus the toolkit conversions that reassembly and traceflow need. They are not required to match the default engine one-for-one, so a disagreement with the default engine is no longer a defect in itself.

Applied to open work:

fix(protocols): the default engine accepts an IPv6 Jumbo Payload option of 65535 octets or less, against RFC 2675 #1687 (this issue): the RFC 2675 rejection goes in the default engine only. The worker's dpkt and scapy adapter changes come out in the next round.
fix(protocols): IPv6.read accepts a header whose Version is not 6 #1680: the same. IPv6.read rejects a Version other than 6 in the default engine only. It no longer needs one PR across every adapter, so it is unblocked.
fix(toolkit): dpkt, scapy and pyshark drop TCP and IPv4 behind some IPv6 extension-header chains #1626 (pyshark behind Mobility/HIP) and fix(engines): dpkt on a nanosecond PCAP and scapy truncate the timestamp under a low decimal precision #1689 (dpkt and scapy under a low decimal precision): both workers are nearly done. I will land them as best-effort improvements, unless you would rather close them as won't-fix.
Existing agreement tests keep pinning today's behaviour. A future gap gets recorded rather than filed as a defect.

i would like to revert the existing agreement tests and implementations as well, to keep the toolkit and engine harness clean

Recorded: the existing cross-engine agreement tests come out, and so does the toolkit and engine code that exists only to make a third-party engine match the default engine. The aim is a clean toolkit and engine harness.

This replaces my earlier note above, so #1626 and #1689 will not be landed. I have stopped both workers; their partial work is kept in their worktrees.

Three read-only inventories are running: the agreement tests; the adapter and harness code, merged PR by PR, with whether each reverts cleanly and in what order; and the CI legs, required checks, docs and tracking issues tied to agreement. Some changes fixed an adapter's own job, such as a crash or malformed data handed to reassembly, rather than agreement. So I will post the full list here, split into revert, keep and unclear, for you to confirm before anything is reverted.