Disallow compactions into L5/L6 for files that straddle a snapshot stripe

[itsbilal]

Currently, sstables in L5 and L6 can contain multiple internal keys for a user key (eg. a del and a set), and even range deletes and range key sets/unsets/dels that haven't been coalesced even within the sstable. This is because of the presence of snapshots at the time of sstable creation. If we can guarantee that sstables in L5 and L6 were all on one side of a snapshot stripe at time of creation, we can greatly simplify some disaggregated storage read-time coalescing (see #2455), at the potential expense of preventing some L4 -> L5 compactions from happening and resulting in more sstables accumulating in L4. That might not be an issue if snapshots are rarely (and decreasingly) used.

Implementation for this should be relatively straightforward, with the compaction picker excluding any files that have a [SmallestSeqNum, LargestSeqNum] overlapping with an open snapshot seqnum, if the compaction is bound for L5/L6.

[sumeerbhola]

Is this issue obsolete given #2465?

[itsbilal]

It's a lot less necessary given that, yes. We still do read-time coalescing for range keys (see ForeignSSTTransformer), and due to EFOS we write less obsolete keys to begin with. Closing this off as the priority of it is low enough to make it not worthwhile doing.