Add a raw cache file format

[folbricht]

The second of the three items left on the constrained-hardware list. Since #610 an entry is already one packed blob, so a file of those blobs is almost free to produce and to load, where the current file re-encodes every entry as JSON with the message base64'd inside it.

Numbers

20 000 entries, idle i7-7600U:

	json	raw
size	345 B/record	124 B/record	2.8x smaller
write	45.6 ms	2.1 ms	21x
read	157.0 ms	24.2 ms	6.5x

The earlier storage investigation projected 165x on write and 31x on read, so it is worth saying why the real figures are lower. Its write prototype wrote into a counting writer that discarded the bytes, so it never did the copy a real write does. Its read prototype skipped validating the messages; keeping that costs about 15 ms of the 24 ms here, and dropping it would make the read ~8 ms and ~19x. Size came out better than projected because these fixtures are short single-A answers, where JSON's field names and base64 weigh proportionally more.

I kept the validation. It matches what the JSON path does, keeps a corrupt record out of the cache instead of letting it take up an entry until a lookup evicts it, and 15 ms once at startup is not the cost worth optimising here.

Format

header:  "\x00RDC" + version byte      once
record:  uint32 length + blob          repeated to EOF

The magic starts with a NUL so it can't be taken for the JSON format, whose records start with {, and so anything that opens the file can see it is binary. The version belongs to the file rather than to each record: it is checked once and a file can't hold a mix. The version byte inside a blob stays reserved for a record that travels on its own, which is what the Redis work would need.

Configuration

backend = {type = "memory", filename = "/var/tmp/cache.bin", file-format = "raw"}

file-format is json (default) or raw, and an unrecognised value is a config error rather than a silent fallback.

It controls writing only. Which format is read comes from the file itself, so turning the option on or off keeps an existing cache instead of dropping it on the floor, in either direction. That seemed worth the five-byte peek; the reader was already buffered, so Peek was free.

binary	file on disk	result
new, json	json	unchanged
new, raw	json	reads json, writes raw
new, json	raw	reads raw, writes json
older build	raw	fails to parse, starts with an empty cache

The default stays json for now: a raw file is unreadable to a build that predates it, and while that degrades to a cold start rather than a failure, the format is worth leaving to soak for a release before the default moves.

Corruption

Same contract as the JSON format, with one difference the framing forces. A record that doesn't decode is skipped and reading continues. A length that can't be trusted has no next record to find from, so reading stops there and keeps what it already has, and a length beyond the largest possible record is refused rather than allocated for; a corrupt four-byte length must not ask for gigabytes.

Tests

Round-trip including queue order and byte-identical rewrite; the format being detected rather than configured, across all four write-then-read combinations through the real backend; a raw file refused by the JSON reader, which is the downgrade path; and the corruption contract, covering a truncated tail, an implausible length, a corrupt message that costs only its own record, a header-only file and a wrong version.

[folbricht]

@emlimap This adds a new raw file-format for cache files that's going to write significantly faster on constraint machines. Also, there are other improvements that make caches faster and more efficient (including much faster GC). You might want to try this to see if it helps.