Re-add elements using the '(re)applied index' index instead of the revert index

[peterjan]

This PR passes an appliedIndex to revertChainUpdate which is used whenever we re-add elements. Before, we were re-adding those elements using the revertIndex which is definitely incorrect because we go and delete those in revertIndex. I renamed revertIndex to removeEvents and changed it to only remove events because if a revert is processed correctly the elements should already have been removed.

The idea of an appliedIndex as the counterpart for every revertIndex feels a bit naive maybe but I decided to propose it nonetheless because I don't see what's wrong with it either. If we can't do that I feel the only thing we're left with is soft deletion but that comes with its own issues, mostly complexity trade-off.

[n8maninger]

Orphans can only be created when a reorg occurs and a rescan is interrupted. This is specific to walletd locking the main scan thread during a rescan. Reverted blocks should never create orphans since they’re reverted properly.

[peterjan]

Orphans can only be created when a reorg occurs and a rescan is interrupted. This is specific to walletd locking the main scan thread during a rescan. Reverted blocks should never create orphans since they’re reverted properly.

I updated the PR to pass the corresponding appliedIndex along with every revertIndex because it's definitely wrong what we are doing currently in revertChainUpdate. When we revertIndex on the very last step we are removing the re-added elements.

[peterjan]

Closing in favour of #109