Migration system does not support more than one migration

[3esmit]

Migration allows a new contract to be accepted by accounts.

The following actions would not follow a third migration:

• When an account starts migration, in would try to migrate to next version, not to latest.
• When an account processes while on migration, it informs of minted MPs on past epochs.

Possible solutions:

1. When receiving migration data, while on migration, forward call to next version. Good: easy to implement. Bad: Will not process under the rules of the intermidiate version
2. Lock ABI of migration and allow direct migration to latest version. Good: Easy to implement, very predictable. Bad: Locked into a certain ABI.
3. Allow owner to change migration address. Good: Cheapest in gas, versatile. Bad: Migration address can change, locked into a certain ABI
4. Architect migration in a way that the migration is processed at each contract. Good: enforce that user passes through all rules for past epoch for the intermediate version. Bad: gas expansive, tricky to implement

There is no perfect solution on that, each of own have its own advantages and drawbacks.

[3esmit]

We decided going for option 4. due requirement in accounts being processed for each epoch in past contract rules.