Revert persistent data related to parachains management

[davxy]

Substrate's CLI "revert" command is supposed to revert the node state by N blocks back to at most the last finalized one and leave the node in a consistent state.

Currently the command reverts:

• blockchain state;
• consensus related aux data (currently babe and grandpa)

It has been observed that some information related to parachains management should be reverted as well.

We can divide the information that has been added by the blocks that follows the revert point in two categories:

1. data that somehow depends on the blockchain state;
2. data that is independent from the blockchain state.

Data that belongs to the first category must be reverted.
If not, it may end up referencing some blockchain data that in the meantime has been wiped out by the overall revert procedure.

Data from the second category is mostly a "nice to have" cleanup feature.
If this is not reverted it should be a (desiderably negligible) leftover that doesn't influence the node's operational status once restarted.

The first step towards the goal is to identify the data that requires to be reverted and then possibly leverage some interfaces that are already present to remove/rollback parachains related data.

For more context about what has already been done see #10962, #11022 and #11162

[davxy]

Any hints @drahnr @rphmeier @eskimor :-) ?

[drahnr]

There are (from the top of my head) two node side databases availability-store and disputes coordinator which both store data referencing either parachain candidate hashes or relay chain hashes

[rphmeier]

there's:

• dispute-coordinator (stores votes by candidate hash / session index. probably doesn't need to be reverted. but there will be some orphaned data until the chain progresses further on the local node)
• availability-store (stores chunks / full data by candidate hash / session index. same, probably)
• chain-selection (does need to be reverted, should be fairly straightforward to do so, but requires some knowledge of how the Polkadot fork-choice rule should work)
• approval-voting (does need to be reverted, should be fairly straightforward to do so - should be quite similar to the existing pruning implementation)