storage: block property filter on tenant,table,index

Within Pebble, keys from different Cockroach tenants, tables and indexes may all share sstables and sstable blocks. Different tenants, tables and indexes tend to have different access patterns. Imagine an infrequently-written, frequently-read tenant/table/index _B_, sandwiched within the keyspace by two frequently-written tenant/table/indexes _A_ and _C_. Over time, it’s likely that the entirety of _B_’s data will reside in L6. However reads of _B_ will frequently find sstables overlapping _B_’s keyspace, containing _A_ and _C_’s writes. Iterators reading from _B_ have no way of knowing that these sstables in higher levels contain no relevant data, so they’re forced to suffer the read amplification of the broader LSM.

One approach to this problem is sstable partitioning/guards (cockroachdb/pebble#517), but this can produce sstables that are smaller than desirable and increase key comparisons when seeking for the appropriate sstable.

An alternative is to define a block-property collector that collects the set of unique (tenant,table,index) tuples contained within ssblocks and sstables. An iterator reading from `///` can set a block-property filter that ignores any blocks with a tenant-table-index block property that indicates it does not contain the sought index. If the iterator finds a sstable that overlaps the sought index's keyspace but does not contain the sought index, it can exclude the sstable without reading it. Cockroach iterators already set an upper bound of the start of the next index's keyspace, which would allow the iterator to exhaust the level without ever suffering a block load.

To reduce the overhead of this new block-property filtering, only sstables/blocks containing keys from more than one index must encode a block property.

Jira issue: CRDB-22329