improve performance of aggregations over a key range using range annotations

[anish-shanbhag]

#3759 introduces range annotations, which compute a query that aggregates a value across a key range within a level. Here are some potential use cases for this feature:

• Calculating the number of keys shadowed by a tombstone-dense key range, for use in the heuristic proposed at docs/rfc: add RFC for point tombstone density compaction heuristic #3719
  • The tentative heuristic at compact: add point tombstone density compaction heuristic #3790 doesn't require range annotations, but this could still be something to consider.
• Computing the total file size that a read compaction overlaps with, which is used to prevent read compactions that are too wide here
• Estimating disk usage for a key range without having to iterate over files, which is done here
• Calculating average value size and compression ratio for a key range, which we currently use when estimating the potential space that compacting point tombstones would reclaim. Range annotations could also be used to implement the TODO from @jbowens.
• Estimating the reclaimed space from compacting range deletions, for which we also currently use sequential iteration.
• Because annotations are in-memory, if we can find a way to refactor those last two without using I/O at all, then this would eliminate the need to defer table stats collection to a separate goroutine for newly written tables.
• Refactoring db.ScanStatistics, which could increase performance significantly over the current implementation where we scan every key in the DB.
• Expand the LSM visualizer tool (tool: lsm visualization tool #508) or the LSM viewer (db: LSM viewer URL generation #3339) to show aggregate statistics about key ranges. Range annotations would allow us to efficiently compute statistics such as # of pinned keys, # of tombstones, etc. in chunks of the keyspace.

Jira issue: PEBBLE-227