Allow index in pruned mode (e.g. -blockfilterindex)

[maflcko]

Indexes can be turned off an on between restarts and they are initially synced on their own thread.

Both are a potential reason they could "lag behind" and thus they appear incompatible with pruned mode. However, if they only lag by MIN_BLOCKS_TO_KEEP, we could allow them to catch up on startup. If they lag behind by more, the background thread might just fetch the blocks from the network?

See also #14121 (comment)

Motivation to maintain indexes in pruned mode is that they can be serve to other peers (p2p), or over rpc, or even be used by the own wallet.

[jonasschnelli]

Maybe also introduce a function that pauses IBD/catch-up in case an index gets close to lagging > MIN_BLOCKS_TO_KEEP.

That functionality could also be useful for external listeners (ZMQ, RPC),... things like lightning daemons (if external applications would have an option to report back their sync state/hash of sync-tip).

[pstratem]

how does the wallet deal with falling behind in pruned mode?

[jonasschnelli]

how does the wallet deal with falling behind in pruned mode?

This is not part of this PR. But I have a branch (you can search for it) where the wallet would request the blocks filtered out and are not available on disk (due to pruning) from the p2p network.

If you meant to ask how wallets deal with that situation in the current master, they would just fail to load (can lead to shutdown during init) if they fall behind prune depth.

[pstratem]

@jonasschnelli yeah, i'm suggesting looking at how the wallet handles this for an idea of how to do so with the filters

[prusnak]

It makes sense for a pruned node to have the blockfilterindex available for non-pruned blocks.

[maflcko]

#15946