Compaction fate operation may not clean up all of its temporary metadata changes

[keith-turner]

When a compaction on a table is initiated via the public API a range can be specified. All tablets that overlap the range are compacted. This is driven by a fate operations that writes temporary tablet metdata. At conclusion the fate operation cleans up this compaction metadata. Concurrent splits could cause tablet metadata related to the compaction fate operation to be copied outside of the range specified in the API. If this happens then the fate operation would not clean up the metadata.

This comment offers a solution to this problem

[ArbaazKhan1]

I can take a look at this