Migration design

[hackfisher]

Regarding the transition from old Staking to new Staking, direct migration is not supported, because it may take a long time to clear. Therefore, you can consider setting a transition period of 2 months, time_since_upgrade_start / 2 months * settings_collator_count uses the new one, and the rest uses the old one.

After 2 months, the old Staking can be runtime_migrated, the legacy RING is returned to the user, and the collator Staking is deleted.

For the settings_collator_count read, the new collator contract returns an error or is insufficient (the insufficient part is filled with 0x0), it is recommended to use the backup address to cyclically fill the empty address. (The backup address is filled with the technical committee address or the development team, and the session key needs to be set in advance, so that it can be backed up at any time)

Deposit supports long-term direct migration to new contract by adding a new migrate runtime call.