persist: Refactor stats away from Box<dyn DynStats> and instead use an enum

[ParkMyCar]

This PR refactors stats handling away from using Box<dyn DynStats> and to using a concrete type called ColumnarStats, which is structured very similar to the ProtoDynStats message type, i.e. it has an inner enum of all the stats types that we can match against.

It should not result in any behavioral change, the statistics_stability test that asserts the generated statistics match a snapshot, is still passing.

Previously the flow worked like ProtoDynStats -> Box<dyn DynStats> -downcast-> T::Stats. The flow in this PR is still very similar, ProtoDynStats -> ColumnarStats -> T::Stats, but now ColumnarStats contains an enum ColumnStatsKind that we can match against in a follow up PR.

Motivation

Related to #24830
Related to #27084

As we write structured data for all of our column types we'll evolve the kind of stats we keep. Currently the kind of stats are 1:1 with the implementation of trait Data that has an associated type Stats. Today we downcast a Box<dyn DynStats> to this associated Stats type, but this doesn't work if there are possibly two different kinds of stats that might exist for a column type. Also, I recently re-worked our column encoders away from the Data trait, and thus the associated Stats type as well.

We don't do it in this PR, but we're now setup to match a column type against a ColumnStatsKind enum which will make it easy to evolve stats over time.

Alternatives

There are two alternatives to match-ing between column type and stats type.

1. For a given column type, downcast to known stats types until we find a match. This works, but feels very non-Rusty.
2. Provide a version number with each Part and then given a version and column type, downcast to a specific kind of stats. This approach doesn't require a refactor but I think we'd still end up with a big match statement?

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:
  • N/a

[bkirwi]

How would you feel about inlining the null count here, and setting it to zero for a non-nullable type?

Seems like it could simplify some downstream code, and I'm not sure the distinction between None and Some(0) is buying us any safety...

[ParkMyCar]

I nested the inner struct so we could differentiate between columns that could have nulls but does not contain any (Some(0)) vs non-nullable columns (None). I don't know if making that distinction is necessary though, so I'm more than happy to flatten it!

[bkirwi]

I don't know if making that distinction is necessary though [...]

Right - I suspected it's not, but you're the one who will know for sure!

[ParkMyCar]

I'm not going to inline the null count for now, in a stacked PR being able to make the extra assertions is kind of nice. Can definitely change this later on though if we want!