blockstorage: keep snapshot base in normal blockfile range #35307

The background chainstate connects the assumeutxo snapshot base block. If that block is stored before loadtxoutset() sets BlockManager::m_snapshot_height, it is written using the normal blockfile cursor.

After snapshot activation, the base height was classified as ASSUMED. If background validation later connected the already-stored base block, WriteBlockUndo() could require an ASSUMED cursor that had not been initialized.

Classify only blocks above the snapshot base height as ASSUMED. Keep the snapshot chainstate flush path from flushing the normal cursor while it is still at the base height.

When loading a snapshot chainstate from disk, keep an already-stored base block in m_blocks_unlinked until its parents are processed, and avoid adding the historical target to setBlockIndexCandidates before then. VerifyDB also stops before disconnecting the snapshot base, where the snapshot database lacks the ancestor UTXO data.

The functional test stores the snapshot base block before loading the snapshot, restarts after snapshot activation, then feeds the missing historical blocks and checks that background validation completes.

Tested:

test/functional/feature_assumeutxo.py --configfile=$PWD/build/test/config.ini --timeout-factor=4
test/functional/wallet_assumeutxo.py --configfile=$PWD/build/test/config.ini --timeout-factor=4

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35307.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #35359 (blockstorage: Remove cs_LastBlockFile recursive mutex by sedited)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

why would someone load a snapshot when they already downloaded the block, which means that their tip must be no more than 1024 blocks behind that block.

I don't think the normal P2P download path is a strong motivation here. In that case, as you say, the node would already be close to the snapshot height.

The case covered here is that this blockstorage state is accepted through local block submission/import before snapshot activation. For example, submitblock can store the snapshot base block while m_snapshot_height is still unset, so it is accounted under the normal blockfile cursor. After loadtxoutset(), the same height maps to ASSUMED; if no assumed blockfile cursor exists yet, background validation can later connect that block and hit the cursor assertion in WriteBlockUndo().

So I’d frame this as making an accepted blockstorage state not abort, rather than as an important/common assumeutxo path. If maintainers prefer not to support that state, rejecting it during snapshot activation would be another possible direction.

Taking this back to draft for now.