`FilterIter` may not handle reorgs properly.

[evanlinjin]

We need to test this against reorgs. It seems like the architecture of this may result in inconsistent state of checkpoints during reorgs.

1. Have a chain with blocks .. [100:A] [101:B] with relevant txs in both A and B.
2. Sync up to 100 (calling .next).
3. Reorg so that blocks from 100 are replaced (inclusive). .. [100:A'] [101:B'].
4. Call .next again.
5. Check that checkpoints end in .. [100:A'] [101:B'] and we have emitted relevant txs in A' and B'.

Originally posted by @evanlinjin in #1614 (comment)

[Musab1258]

@evanlinjin, can I work on this?

[ValuedMammal]

To fix this I would avoid this pre-fetching of blocks and just fetch every block hash/header by height. If we encounter a header with a previous hash that doesn't match the previously emitted block id, we know we need to backtrack and refetch filters until we've formed a consistent chain.

bdk/crates/bitcoind_rpc/src/bip158.rs

Lines 104 to 106 in ea150b4

	// if we have a checkpoint we use a lookback of ten blocks
	// to ensure consistency of the local chain
	if let Some(cp) = self.cp.as_ref() {

I wonder is it necessary to perform this reorg check at every height in a scan or only the blocks that lie within some fixed arbitrary distance from the stop block?