State Migration interface

[birchmd]

State migrations may be necessary for some contract upgrades. Presently it is assumed we will write them ad-hoc when needed and it will run as part of the normal upgrade flow (see tests/test_state_migration.rs for an example).

The purpose of this discussion is to determine if we should have a DSL for describing general state migrations and use this instead of changing the contents of the state_migration function. If we do want such a DSL then what should it look like?

cc @sept-en @mfornet @mrLSD

[mfornet]

@mrLSD @sept-en can you explain the design you made for state-migration. Please describes pros and cons of it.

Some issues for general purpose migration I see are:

1. Number of function-calls + consumed gas required to migrate state may be large depending on the number of keys to change. For example it is not the same when the number of changes are constant vs proportional to the number of users/tokens/other enumerable identities).
2. State migration can't be done atomically (several function-calls are required in some cases) so this means that while migration is taking place, state of the contract might be in an inconsistent state. (We need to prevent users from interacting with a contract in an inconsistent state)
3. Because of 2), this may cause a downtime in the contract (can this be prevented/minimized?)

[mfornet]

If we are going for a general purpose solution, we should also consider open a PR/Discussion on https://github.com/near/NEPs/, with the proposal (this doesn't mean we need to get blocked on it to be accepted) but this way we will help the community with an initial standard, and we will get more feedback on our current approach.

[mfornet]

Relevant NEP: near/NEPs#123 (though state-migration in particular is not discussed)