storage: Fast approximate snapshot partitioning

[peterdukelarsen]

Motivation

The boundary computation for parallel snapshotting was about as slow as the single-threaded snapshot in many cases, i.e.
Parallelized (~2h runtime):

Single-threaded (~1h50m runtime):

With this change we got rid of the boundary computation and were able to snapshot 1B rows in ~16m:

Follow this anchor link for full details on the specs/data: https://app.notion.com/p/materialize/MySQL-Parallel-Snapshot-Smoke-Test-3a613f48d37b806fa311d1bfe9d4ec4c?source=copy_link#3a913f48d37b80a3bbb2dd05f6bc94c2

Description

Probes the values of a single-column string primary key using EXPLAIN and SELECT LIKE queries to compute approximate partitioning.

In slightly more detail we:

1. Grab all of the unique first characters of the primary key strings and use EXPLAIN to estimate their row count
2. For any character with a high row count we will redo the process one character deeper
3. We continue stepping down into longer prefixes until we run out of a configured number of calls to make or we've resolved granular enough buckets to build partition boundaries
4. Finally, we pick partition boundaries based on the total estimated row count (which could diverge from the real row count or the regular estimated row count by a good bit), and just walk the partitions in order computing boundary keys, which are just prefixes.

Downsides

1. Complexity
2. Won't work in all cases -- particularly any cases with extremely high cardinality characters in their prefixes could devolve. To work around this we'll follow up with implementing some caps on the number of queries we make and/or the time we spend, but obviously that will just prevent regression not make this work for all collections of string PKs.

Verification

1. Deployed 777e7e8 to staging and snapshot 1B row table (August 3, around noon-3pm EDT)

---

Recreated from #37994 with an in-repo head branch so this PR can join the GitHub stack.