persist: Add more testing around stats

[ParkMyCar]

This PR adds some more testing around our Part statistics. Specifically it adds two new tests:

1. A proptest for correctness. We generate arbitrary ColumnTypes, and use that ColumnType to generate an arbitrary Vec<Row>, then we calculate stats on that collection of Rows and assert that every Row would be included in the stats.
2. A test for stats stability. We use proptest with a constant seed to generate 1,000 instances of RelationDescs with at most 4 columns, then a collection of at most 8 Rows for these RelationDescs. We generate statistics for all 1,000 scenarios and then take a JSON snapshot of the stats. This test helps us track if any changes occur to our statistics generation.

I'm curious what folks thoughts are on the second test, I'm more than happy to not merge it and use it only to validate #27009, if we don't think it provides a ton of signal.

Motivation

Protect against stats breaking, e.g. in changes like #27009

Tips for reviewer

The PR is broken up into 2 commits:

1. Proptest strategies to generate Datums from a ColumnType, and adding the first test.
2. The snapshot test.

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

[ggevay]

arb_datum_for_column could also be used for scalar function property testing! For each scalar function, we could generate some random inputs of the appropriate type using arb_datum_for_column, call the function, and check whether propagates_nulls, is_monotone, and all the other things on LazyUnaryFunc are actually true about the results we got. I'll open a follow-up PR for this. I'd be willing to bet a non-trivial amount of money that this will reveal some bugs. E.g., just a few minutes ago we found some wrong inverse annotations on some exotic cast functions. (We already have test_smoketest_all_builtins, but that currently uses some hardcoded interesting_datums as inputs. Making it use random inputs should be more effective.)

[danhhz]

Very cool! @bkirwi mind taking the review on this one?

[ParkMyCar]

@ggevay nice! Glad y'all can also find a use for the proptest impls here!

[bkirwi]

Nice!