Background compact increases the chances of running compact on a table that has concurrent writer threads. This causes compact to get "stuck" on table for various reasons. We should stop compacting a table if it grows in size between compact passes as this indicates compact is unlikely able to reclaim space. During compaction the block manager is set to "first fit" mode so any concurrent writes should write towards the front of the file. If this is not possible, then it will write to the end of the file extending the file size. If this occurs, the compact thread is also unlikely able to rewrite any blocks in the first 90% and we should exit the compaction loop.