Flat variant serialization bench - #6843

ArchivedVec::serialize_from_slice resolves a slice element by element
unless rkyv's nightly-only copy feature is on, so serializing a document
cost one write call per byte rather than the single bulk write the module
documentation claims. serialize_copy_from_slice writes it once. A byte is
trivially copyable, has no padding, and archives as itself, so the copy
is exactly the encoding.

Measured by benches/flat_variant_serialize.rs on 100,000 documents of
16 KiB, paired back to back in one machine state:

    mode                       before              after
    fresh FBuf per document    3.689 s  424 MiB/s  0.056 s  27 GiB/s
    shared FBuf                3.574 s  438 MiB/s  0.033 s  47 GiB/s

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

The derived rkyv::Serialize delegated to SmallVec's, which resolves the
payload element by element, one write call per byte. Hand-writing the impl
around serialize_copy_from_slice writes it once. A byte is trivially
copyable, has no padding, and archives as itself, so the copy is exactly
the payload, and the archived layout does not change: an ArchivedVec<u8>
either way, so existing storage stays readable.

Every BINARY and VARBINARY value pays this on each batch write to storage
and each checkpoint, and so does Variant::Binary. Measured on 16 KiB
values, against the untouched Vec<u8> path as a control in the same run:

    Vec<u8> (per element)     97.808 ms   0.31 GiB/s
    ByteArray (bulk copy)      1.118 ms  27.30 GiB/s

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

Checkpoint::checkpoint returns state already serialized, and the committed
structs that carry it hold it as Vec<u8>, whose rkyv impl copies it back
out one byte per write call. rkyv's CopyOptimize wrapper writes it once.

Annotated: CommittedZ1 and CommittedTransactionZ1, which carry a whole
operator state, and CommittedClock, which is small but free to fix.
CommittedWindow keeps the per-element path, because the wrapper applies to
a Vec field rather than through an Option of a tuple and a pair of
serialized keys is not worth reshaping the struct for; the reason is now
recorded there.

Serializing a CommittedZ1 with a 16 MiB blob, paired back to back:

    before  13.304 ms/pass   1.17 GiB/s
    after    1.419 ms/pass  11.01 GiB/s

Restore gets faster too, since the wrapper deserializes with one
copy_nonoverlapping instead of a per-element loop.

The archived layout is unchanged, so checkpoints written by earlier builds
still restore. bulk_copy_keeps_the_committed_layout pins exactly that: it
compares the archived bytes against a reference struct that has no wrapper,
and fails if the wrapper ever changes the layout, which a swap to AsBox
confirms.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>

ByteArray::size_of_children delegated to its SmallVec field, and there is
no SizeOf impl for SmallVec, so the call resolved to the one for [u8]: it
walked the bytes, reported none of the buffer holding them, and left a
16 KiB VARBINARY value claiming 48 bytes. Count the spilled allocation the
way Vec counts its own. An inline payload needs nothing added, being part
of size_of::<ByteArray>() already.

The undercount was total rather than approximate, and BINARY and VARBINARY
are the only SQL types affected: SqlString wraps an ArcStr, which
feldera-size-of does support, and FlatVariant reports its Arc buffer.

What read the wrong number: the fallback batches size their contents with
size_of().total_bytes() per key, value and weight
(trace/ord/fallback/indexed_wset.rs:568-654) to decide when a batch moves
to storage, so a batch of large binary values looked nearly free and stayed
in memory. Expect such batches to spill sooner now, which is the point.

Dropping the delegation also drops a per-byte loop that computed nothing.

Found by the FlatVariant serialization benchmark, whose VARBINARY corpus
reported 4.6 MiB of heap for 1.5 GiB of payloads.

Signed-off-by: Leonid Ryzhyk <ryzhyk@gmail.com>