<!-- Describe the issue -->

When our chainstate activation sequence fails and we're running the GUI, we ask the user via a question box whether or not they'd like to re-run the sequence with `fReindex = true`. Fun fact: despite the fact that this sequence is wrapped in a while loop, we only run it twice at most.

https://github.com/bitcoin/bitcoin/blob/7ecb309c4ed1bb9ae6b9a12cbb4f083328edc125/src/init.cpp#L1539-L1556

If they answer yes, the sequence will always fail, because a chainstate will have already been initialized in the original run and `InitializeChainstate` will throw a `std::logic_error`:

https://github.com/bitcoin/bitcoin/blob/7ecb309c4ed1bb9ae6b9a12cbb4f083328edc125/src/validation.cpp#L4573-L4594

This always reproduces. To reproduce:
```
gdb ./src/qt/bitcoin-qt
(gdb) b InitializeChainstate
(gdb) # add breakpoint for the "if (!fLoaded && !ShutdownRequested()) {" line
(gdb) r  # should stop at the breakpoint for InitializeChainstate
(gdb) c  # to advance to the breakpoint for the "if (!fLoaded && !ShutdownRequested()) {" line
(gdb) set fLoaded=false
(gdb) c  # should stop at the breakpoint for InitializeChainstate
(gdb) n  # step through InitializeChainstate to see that it throws
```

We expect the re-run of the chainstate activation sequence to not always fail.

{
    friend CChainState;
    friend ChainstateManager;
private:
    /**
     * Load the blocktree off disk and into memory. Populate certain metadata
     * per index entry (nStatus, nChainWork, nTimeMax, etc.) as well as peripheral
     * collections like m_dirty_blockindex.
     */
    bool LoadBlockIndex(const Consensus::Params& consensus_params)
        EXCLUSIVE_LOCKS_REQUIRED(cs_main);
    void FlushBlockFile(bool fFinalize = false, bool finalize_undo = false);
    void FlushUndoFile(int block_file, bool finalize = false);
    bool FindBlockPos(FlatFilePos& pos, unsigned int nAddSize, unsigned int nHeight, CChain& active_chain, uint64_t nTime, bool fKnown);
    bool FindUndoPos(BlockValidationState& state, int nFile, FlatFilePos& pos, unsigned int nAddSize);
    
    void FindFilesToPruneManual(std::set<int>& setFilesToPrune, int nManualPruneHeight, int chain_tip_height);
    /**
     * Prune block and undo files (blk???.dat and rev???.dat) so that the disk space used is less than a user-defined target.
     * The user sets the target (in MB) on the command line or in config file.  This will be run on startup and whenever new
     * space is allocated in a block or undo file, staying below the target. Changing back to unpruned requires a reindex
     * (which in this case means the blockchain must be re-downloaded.)
     *
     * Pruning functions are called from FlushStateToDisk when the m_check_for_pruning flag has been set.
     * Block and undo files are deleted in lock-step (when blk00003.dat is deleted, so is rev00003.dat.)
     * Pruning cannot take place until the longest chain is at least a certain length (CChainParams::nPruneAfterHeight).
     * Pruning will never delete a block within a defined distance (currently 288) from the active chain's tip.
     * The block index is updated by unsetting HAVE_DATA and HAVE_UNDO for any blocks that were stored in the deleted files.