I took a cursory look; this patch makes compactor also pluggable and makes it return multiple files, and moves the default compaction policy stuff off the base class.
If compactionPolicy returns, I wonder if (while Compactor is separate for reuse) it makes sense to make compactionPolicy interface simpler, and just let it compact. E.g. if Store has no default selection stuff anymore it doesn't make sense for it to get selection and feed it into compactor, right?
Then, does it make sense to change CP interface to be called for all files post compaction instead of one file? I am not sure what use-cases it has, but there's no way to tell apart different compaction algorithms.
My main concern is that this patch does not allow us to implement level compaction as described (see txt in level compaction issue). We can implement different algos which will allow for gradual compaction at the cost of IO, but not level algorithm, because that will remove the file ordering by seqNum, break the heuristic for determining mid-point for split, and other things.