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):

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 implement some caps on the number of queries we make, but that will mean this doesn't apply to all string PK shapes.

Verification

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