persist: Add FixedSizeBytesStats

[ParkMyCar]

This PR adds a new variant of BytesStats called FixedSizedBytesStats. It's very similar to AtomicBytesStats in that they can't be trimmed, but they're explicitly for types that implement the new FixedSizeCodec.

Motivation

Related to #24830

As we evolve our encodings in Persist, what bytes are recorded will change. For example, today stats for ScalarType::Time are AtomicBytesStats of a ProtoNaiveTime, but with our new columnar encodings it will be a PackedNaiveTime. We need a way to distinguish between the two.

An alternative is adding a "kind" field to AtomicBytesStats, I originally implemented this but we determined the better approach would be a whole separate type which allows for a cleaner separation.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:

[bkirwi]

IIRC we discussed using a part-level version number to manage migrations at the actual data level; wondering if that would make sense here.

Personally I kind of appreciate the PackedBytesStats idea... while in many ways it is similar to the atomic stats as you mention, there are important differences: it has a meaningful sort, and it can be computed off the columnar representation instead of the raw data. (One option would be to call it FixedLengthBytesStats or whatever, which stresses that while the proto types are similar we're dealing with a different sort of thing at the arrow level.)

[ParkMyCar]

IIRC we discussed using a part-level version number to manage migrations at the actual data level; wondering if that would make sense here.

For sure! I thought about adding a version number to stats, and it definitely should be possible, just a bit heavier weight. In the meantime I realized at the moment the only type of stats that we really need to evolve are the AtomicBytesStats and just adding a "kind" here was faster than adding a version.

Personally I kind of appreciate the PackedBytesStats idea... while in many ways it is similar to the atomic stats as you mention, there are important differences: it has a meaningful sort, and it can be computed off the columnar representation instead of the raw data. (One option would be to call it FixedLengthBytesStats or whatever, which stresses that while the proto types are similar we're dealing with a different sort of thing at the arrow level.)

Totally fair, and it is a cleaner separation between the older stats types and the newer types. I'll update this PR to add a PackedBytesStats instead of adding a "kind" to AtomicBytesStats

[bkirwi]

🙏