The structure of the files is as such.
StripeStoreEngine is implementation of StoreEngine for stripes, should be pretty straightforward. needsCompaction from CompactionPolicy was moved into storeEngine, and in case of each engine calls the appropriate method.
StripeCompactor is a placeholder for compactor; does nothing now. Again, due to vast differences in compactor interfaces general Compactor lost compact methods.
DefaultCompactionPolicy was refactored a bit to extract the application of the ratio algorithm into a static method for use in stripes. I added minfiles check right in the method; I'll check whether separate minfile check that default policy does can be removed.
Then, StripeStoreConfig is a base class now; it has two nested sub-classes for size-based and count-based stripes, with different parameters.
StripeCompactionPolicy is the base policy class that is gene has some common methods, the biggest of which is finding single-stripe compaction. It's generic on StripeStoreConfig type.
SizeBasedStripeCompactionPolicy and CountBasedStripeCompactionPolicy are the actual implementations of the two policies.
Tests for each class are straightforward (in terms of mapping test to class); StripeCompactionPolicyTestBase is a base class that contain various common methods to create mock state, verify things, etc.
Also: discussion of drop-deletes logic is in
In short, to drop deletes, we need to add L0 files to compaction to have all store files, lest we have issues with deletes/puts in the past. Then we can only drop deletes from stripe files, not L0. Note that we already have the issues with that because of memstore, but the timing window to get it is relatively small, whereas if we ignore some store files it will be large.
Therefore, I added a config parameters "assume ordering", which basically tells us the user is prepared to tolerate it or doesn't use deletes in the past much (I assume this is majority of cases, but it's off by default). In that case we can drop deletes on the compactions of entire stripe, ignoring L0.
Then, to avoid blowing up the compaction size/rewrites, I added a ratio config, where L0 will not be added to compaction to drop deletes unless it's small enough. I will need to think more about that, as adding very small L0 to compaction can result in a different kind of problem, too many small files.
Needless to say if there's no L0 (no files), we don't have to add it.
Finally, in order to add L0 files to compaction to drop deletes, we need to know the resulting stripe boundaries (to split L0), so it's not done for compactions that are based on determining the boundaries dynamically (e.g. rebalancing, where we determine boundary in compactor based on data size).