kernel: add prune locks and target pruning #36857

Without this, -prune and -fastprune in extra_args have no effect.

Move the blk file aside instead of deleting it, so it can be restored.

The pruned blk/rev files are not deleted, even after a later flush
succeeds.

Files selected for pruning were kept in a local, so a failed flush left
them on disk until the next startup.

Keep them in BlockManager and delete them after the next block index
write. Take them with the dirty entries, which WriteBlockIndexDB() drops
even if the write fails. Drop a file from the set once a block is
written to it.

Pending files wait for the next periodic, forced or shutdown flush
rather than forcing one, which would retry a failing write on every
block.

Move the block and undo file flush, block index write and pruned file
deletion from FlushStateToDisk into BlockManager. Their bench log lines
change from FlushStateToDisk to WriteBlockStorage.

Validation read BlockManager's prune locks directly. Move that code and
PRUNE_LOCK_BUFFER into BlockManager.

BlockManager read the chainstate to decide what to prune. Decide in
validation and pass the height range and sizes instead. An Assume checks
the heights are non-negative.

Move FlushStateToDisk's handling of the prune request, prune locks,
pruned flag, files to delete and blocks directory space check into
BlockManager. The prune request is cleared before the prune locks are
applied rather than after selection, which differs only if selection
throws.

An Assume checks that the pruned flag is set before files are queued
for deletion, so a restart knows blocks were deleted.

ChainMan declares m_context last, which destroys it before the
ChainstateManager that refers into it. Reset the chainstate manager
explicitly, making the order independent of member declaration order.

Create the BlockManager first and pass it in by reference. NodeContext
and the kernel own both and destroy ChainstateManager first.

The block tree database opens before the script verification threads
start, which swaps their startup log lines.

The flag duplicated the BlockManager's prune mode. Init and the test
setup copied it, and the kernel left it false. Check the BlockManager
directly, keeping one source of truth before the kernel can enable
pruning.

Block storage was configured and read through the chainstate manager.
Add btck_BlockManagerOptions and btck_BlockManager, and pass the block
manager to btck_chainstate_manager_create, which keeps a shared
reference, so either can be destroyed first. A block manager serves
one chainstate manager.

btck_block_read and btck_block_spent_outputs_read take the block
manager. Each options object takes the total database cache and uses
its part. Wiping the block tree db also wipes the chainstate db.

Add a block manager prune option and
btck_block_manager_prune_up_to_height. The option also lets the kernel
open data directories Bitcoin Core has pruned. The chainstate manager
created with the block manager decides what may be deleted, so pruning
fails without one.

Pruning writes only block storage. It keeps blocks above the last
chainstate flush, which the chainstate on disk may still need after an
unclean shutdown, and reports when it did. Add
btck_chainstate_manager_flush to flush before pruning again.

Add a fast prune option for tests, since test chains never fill a
128 MiB block file.

An application that reads blocks after they are connected needs them
kept until it has read them. Add block manager functions to set and
delete prune locks.

The kernel needs the room FindFilesToPrune keeps below a prune target.

An application that wants block storage kept below a size would have
to pick prune heights itself. Add btck_block_manager_prune_to_target,
which deletes the oldest blocks until usage is below a target and keeps
the same blocks as btck_block_manager_prune_up_to_height. The kernel
never prunes on its own, so the caller decides when.

Target pruning uses BeginManualPrune. BeginTargetPrune only proceeds
after a new block file is allocated, and the periodic flush in block
processing already consumes that.