rewind_single_block slow for large rewinds

[antiochp]

Related #3236

The introduction of rewind_single_block() makes the output_pos handling more robust but naively involved a call to apply_to_bitmap_accumulator() for each block being rewound.
This is fine for relatively short rewinds such as during a fork or potential reorg scenario.

We have one use case for large rewinds though - this occurs when we are taking a "snapshot" of the txhashset at the horizon to provide to a peer during fast sync. Here we rewind approx 2 days of blocks.

We need to build a vec of "affected pos" across the full set of rewound blocks and then call apply_to_bitmap_accumulator() once with this aggregate set of pos.
It is too costly to do this specific rewind step for each block sequentially.

[antiochp]

This was not identified during testing for #3236 as the performance regression is on the node being sync'd from, not the node doing the syncing.
We should have considered this use case when thinking through potential impact.

[antiochp]

Fix coming shortly.