compute: thin peek results by partitioning, not sorting

[aljoscha]

Motivation

Part 2 of 2 in a stack that makes index peeks stop monopolizing the compute
worker. Part 1 is #38040. A replica crash fix in the same code went first, in
#38039, and has landed.

When a peek's finishing bounds how many rows it can need, the scan keeps twice
that many and periodically drops the excess. It did so by sorting the whole
buffer and truncating. That costs a log factor per row for an order that is
thrown away: the result is ordered once at the end, when the RowCollection is
built. Each comparison decodes both rows, so for a peek with an ORDER BY and
a small LIMIT over a large arrangement this is the dominant cost.

Part of CPU-195.

Description

select_nth_unstable_by gives the same retained rows in O(n) comparisons
instead of O(n log k).

The partition is not stable, so when rows tie across the cut it is unspecified
which of them survives. That is unobservable, and the argument is worth stating
because it is the only thing making this a safe swap:

• A tie under RowComparator::compare_rows(l, r, || l.cmp(r)) means the
  order_by columns compare equal and the tiebreaker compares equal, and the
  tiebreaker is a full comparison of the encoded rows. So tied rows are
  byte-identical.
• The retained run therefore agrees with any other choice on its first
  limit + offset rows, whichever way the cut lands.
• RowSetFinishing::finish reads exactly offset..offset + limit of the merged
  result, and merge_sorted's output prefix depends only on the runs' prefixes.
  So the client sees the same rows either way.

mz_index_peek_result_sort_seconds is renamed to
mz_index_peek_result_thinning_seconds, since it no longer times a sort. The
one remaining sort, when the RowCollection is built, is timed by
mz_index_peek_row_collection_seconds.

Not changed on purpose. The unconditional sort in RowCollection::new,
which fires even when order_by is empty, stays. It is load-bearing for
determinism, not for correctness: per-worker peek responses are absorbed in
arrival order by a randomized StreamMap, so sorting each run by encoded bytes
plus a byte-order k-way merge in envd is what makes client-visible row order
reproducible independent of worker count and arrival order. Roughly 1100
multi-row, no-ORDER BY, nosort sqllogictest goldens ride on it, and
test/sqllogictest/range.slt:359 pins the length-first-then-bytes encoding
order exactly.

Verification

Covered by the existing suite: any change to which rows survive thinning, or to
their order, shows up in the sqllogictest goldens described above, since they
compare output positionally.

[linear-code]

CPU-195