WT-7724 identified a race when we have concurrent checkpoint and flush_tier calls. That ticket provided a "quick fix" of taking the checkpoint lock during the competing portion of flush_tier.  

Intuitively, this seems unnecessary. We should be able to flush_tier during a checkpoint. The required coordination can happen in the block manager, which simply has to ensure that every block is written and that at some point before we flush it to the shared tier, we have to stop writting blocks to the old file/object.

As described in WT-7724, the actual race seems related to the cached checkpoint list introduced in WT-7381. 

The goal of this ticket is to understand the actual race and introduce a (hopefully) lower-cost way to avoid it.