Execution Header Cleanup Multi-Block Migration

[claravanstaden]

Migration to cleanup the previous implementation's execution headers. Execution headers are no longer stored in Snowbridge 1.1.0 and sent with the message instead.

• includes removed github action workflows from upstream
• remove pallet_timestamp from the Ethereum client, since its not used
• adds pallet_migration to the Ethereum client and Rococo runtime
• moves the Snowbridge Rococo runtime config to its own module, to match the Kusama and Polkadot runtime config module structure

Note: The step migration weight is slightly overweight. It specifies 4 writes instead of 2, 12_000_000 weight instead of 10_000_000. The reason is because the ExecutionHeaderIndex and LatestExecutionState is cleaned up in the last step of the migration. In the benchmark code, even if there is only 1 header added to storage, the last step to cleanup ExecutionHeaderIndex and LatestExecutionState will still be executed. I have not found a way to prevent the last step from running. I think this is OK though, rather overweight than underweight, and the discrepancy is small (the migration might run for 1 block longer than necessary).

[yrong]

Cool. Though my concern is what we do here is a trivial task to delete the unused storage, so I'm a bit hesistant to use MBM for that.

The problem is that the chain is in lockdown mode(i.e. not allowing any transaction) for as long as an MBM is ongoing.

polkadot-sdk/substrate/frame/executive/src/lib.rs

Lines 554 to 560 in e96ce3a

	fn extrinsic_mode() -> ExtrinsicInclusionMode {
	if <System as frame_system::Config>::MultiBlockMigrator::ongoing() {
	ExtrinsicInclusionMode::OnlyInherents
	} else {
	ExtrinsicInclusionMode::AllExtrinsics
	}
	}

[claravanstaden]

Cool. Though my concern is what we do here is a trivial task to delete the unused storage, so I'm a bit hesistant to use MBM for that.

The problem is that the chain is in lockdown mode(i.e. not allowing any transaction) for as long as an MBM is ongoing.

polkadot-sdk/substrate/frame/executive/src/lib.rs

Lines 554 to 560 in e96ce3a

	fn extrinsic_mode() -> ExtrinsicInclusionMode {
	if <System as frame_system::Config>::MultiBlockMigrator::ongoing() {
	ExtrinsicInclusionMode::OnlyInherents
	} else {
	ExtrinsicInclusionMode::AllExtrinsics
	}
	}

Hey @yrong! It is true that MBM might be blocking, however I am not too worried about it because the migration will take a single digit number of blocks to complete the migration.

Calculation:

• One migration step (removing 1 executing header) takes 12_000_000 weight.
• The max number of execution headers on prod will be 8192 * 20 = 163,840 headers to clear.
• The weight used to remove all the headers will be 12_000_000 * 163,840 = 1_966_080_000_000
• The block weight on BH is 560_880_000_000. Say 75% of the block space can be used: 420_660_000_000.
• Then the migration will take less than 5 blocks to complete. I think this is acceptable, given BH isn't super busy anyway. But we can check this when we make the PR upstream too.

[vgeddes]

Looks good! Please upstream this :)