Generic nuke migrations

[lemunozm]

Description

This PR adds a nuke migration utility agnostic from any pallet to be used when we need to restore the storage of a pallet. Located in runtime-common.

To nuke the migration of a pallet you need to add the following line (supposing we want to nuke Loans from on-chain version 1):

runtime_common::migrations::nuke::Migration<Loans, RocksDbWeight, 1>

This PR do not remove/add any runtime migration

Partial_fix #1461

Testing

Tested in Altair (previously modifying the runtime by adding this migration) with the following:

RUST_LOG=runtime=trace,try-runtime::cli=trace,executor=trace cargo run --release --features try-runtime try-runtime --runtime target/release/wbuild/altair-runtime/altair_runtime.wasm --chain centrifuge on-runtime-upgrade live --uri wss://fullnode.altair.centrifuge.io:443

Done positive (when it works) & negative (when it shouldn't work) testing

[wischli]

The code LGTM! I was wondering though whether it was desired not to apply the migration to any runtime? Just realized this after I could not get any logs when running against Altair or Centrifuge.

[mustermeiszer]

I would merge after #1493

[lemunozm]

I was wondering though whether it was desired not to apply the migration to any runtime? Just realized this after I could not get any logs when running against Altair or Centrifuge.

@wischli, yeah, it all depends on the chain state at the moment of the runtime upgrade (at least for pallet-loans and pallet-interest-accrual). By now, it's added as a utility. On the release day, we should check those storages and add the nuke migration for them. Or maybe it would be more safe adding them now and remove whatever we found on the runtime upgrade day 🤔

[wischli]

@wischli, yeah, it all depends on the chain state at the moment of the runtime upgrade (at least for pallet-loans and pallet-interest-accrual). By now, it's added as a utility. On the release day, we should check those storages and add the nuke migration for them. Or maybe it would be more safe adding them now and remove whatever we found on the runtime upgrade day 🤔

If this migration is planned to be part of the next release, I would like to add it now as otherwise the verification of the correctness of the migration will only be done during release and not as part of this PR. I don't have a strong opinion about this.

[lemunozm]

For me, the purpose of this PR is only to add this utility for future usage in a common place, without affecting any behavior.

I can add a next PR with the required changes just after merging this in altair/centrifuge runtimes to remove old migrations and add this nuke migration to the required pallets for the next upgrade. WDYT? Just for splitting concerns in different PRs

[wischli]

Thanks for the conversation! Definitely in favor of splitting up PRs such that the addition to corresponding runtimes can be done in a subsequent PR.

[wischli]

Re-approving