Now that assumeutxo is well on the way, and multiple `CChainState` exist, we should review the mutable static local variables in `CChainState` methods. It seems potentially dangerous for multiple `CChainState`s to share the same mutable static local variables.

In `CChainState::FlushStateToDisk`:
https://github.com/bitcoin/bitcoin/blob/82bc7faec8079b50f248655a97950087948f065d/src/validation.cpp#L2154-L2155

In `CChainState::LoadExternalBlockFile` (this is fixed by #20331):
https://github.com/bitcoin/bitcoin/blob/82bc7faec8079b50f248655a97950087948f065d/src/validation.cpp#L4286

ping @jamesob 

-----

Now that I think about it... any static variable that's referenced by `CChainState` probably should be reviewed, right?
{
    
    CRITICAL = 2,
    
    LARGE = 1,
    OK = 0
};
/**
 * Chainstate stores and provides an API to update our local knowledge of the
 * current best chain.
 *
 * Eventually, the API here is targeted at being exposed externally as a
 * consumable libconsensus library, so any functions added must only call
 * other class member functions, pure functions in other parts of the consensus
 * library, callbacks via the validation interface, or read/write-to-disk
 * functions (eventually this will also be via callbacks).
 *
 * Anything that is contingent on the current tip of the chain is stored here,
 * whereas block information and metadata independent of the current tip is
 * kept in `BlockManager`.
 */
class Chainstate