db: prefer compacting into L6 tables with many tombstones

[jbowens]

When picking a file to compact into L6, we consider the L6 file's RangeDeletionBytesEstimate, prioritizing compactions that will compact L6 files with a high estimate:

pebble/compaction_picker.go

Lines 1096 to 1107 in 431a23b

	// For files in the bottommost level of the LSM, the
	// Stats.RangeDeletionsBytesEstimate field is set to the estimate
	// of bytes /within/ the file itself that may be dropped by
	// recompacting the file. These bytes from obsolete keys would not
	// need to be rewritten if we compacted `f` into `outputFile`, so
	// they don't contribute to write amplification. Subtracting them
	// out of the overlapping bytes helps prioritize these compactions
	// that are cheaper than their file sizes suggest.
	if outputLevel == numLevels-1 && outputFile.LargestSeqNum < earliestSnapshotSeqNum {
	overlappingBytes -= outputFile.Stats.RangeDeletionsBytesEstimate
	}

We do this because when we populate RangeDeletionBytesEstimate, we'll estimate the size within the file itself to capture the fact that the range deletions delete data within the file itself (and presumably still exist due to LSM snapshots that were open when the file was created):

pebble/table_stats.go

Lines 422 to 424 in 431a23b

	if level == numLevels-1 && meta.SmallestSeqNum < maxRangeDeleteSeqNum {
	size, err := r.EstimateDiskUsage(start, end)
	if err != nil {

The compaction picking logic does not take into account PointDeletionBytesEstimate. The PointDeletionBytesEstimate doesn't have any special logic accounting for L6 sstables. My reading of the code is that it already includes the size of the tombstones themselves in the estimate, so it's already optimistic in its calculation.

We should update the compaction picking logic to also consider the PointDeletionBytesEstimate when computing the min-overlapping ratio of a compaction.

Jira issue: PEBBLE-411