[MBM] Expose migrating keys

[ggwpez]

Multi Block Migrations can cause chain indexers and explorers to not be able to decode specific storage prefixes since their storage layout is changing. There is currently no way for the outside world to know what keys the runtime is migrating.

One way to achieve this would be to add a function to the SteppedMigration trait:

pub trait SteppedMigration {
    fn migrating_prefixes() -> impl IntoIterator<Item = Vec<u8>> {
	core::iter::empty()
    }
}

This will then be aggregated into the SteppedMigrations trait with a nth_migrating_prefixes function that returns the prefix iterator for the nth migration.

To expose this information to the public, a Runtime API can be provided (if we dont have view functions then). It would query the Migrations::Cursor and then lookup the nth iterator and return all keys into a collected vector.
This should not need any modifications to the migrations pallet or frame-executive.
Eventually, we can wrap the more pallet-centric aspects of MBMs into a PalletMBM trait and populate this automatically with the pallet prefix.

[lean-apple]

Hello @ggwpez, can I work on this issue ?

[ggwpez]

Yes sure 😄 , please write here if there are Qs coming up.

[lean-apple]

Yes sure 😄 , please write here if there are Qs coming up.

Thanks I would like to clarify the different steps to enable to access to the migration keys :

• add SteppedMigration::migrating_prefixes for the default impl to return empty iterator
• add SteppedMigrations, fn nth_migrating_prefixes to get storage prefixes from the nth migration in the tuple
• add tests to verify that nth_migrating_prefixes correctly returns storage prefixes for each migration in a tuple
• create MultiBlockMigrationsApi to expose which storage keys are being modified in the currently running migration
• add API tests
• future improvement: create PalletMBM trait to automatically create storage prefixes from pallet name rather than manual specification

[ggwpez]

Yes sounds good.