Migration function between cloud providers.

[antaeus1986]

We need a function similar to "resize".
Only difference will be that "migration" - will transfer already registered Darknode, to another provider. Without loss of registration of the dark node. This can be useful if one of the providers is experiencing global problems, for example if AWS has a massive failure (or service degradation) and Darknode owner quickly notices failure, they should be able to migrate the Darknode to another provider.

Examle:
# darknode migrate YOUR-DARKNODE-NAME --do --do-token YOUR-API-TOKEN
or
# darknode migrate YOUR-DARKNODE-NAME --aws --aws-access-key YOUR-AWS-ACCESS-KEY --aws-secret-key YOUR-AWS-SECRET-KEY

This will not only reduce the technical risks, but also protect us from the risks of changing license agreements against cryptocurrencies.
And it would be good if the command "darknode list" showed on what cloud provider Darknode works.

[antaeus1986]

And most important question, it is possible to make migration if virtual server will be switched off? Or in order to make the migration a virtual server needs to be launched?

[loongy]

Great idea, we’ll add this to our dev pipeline. The server does not need to be on (the cloud provider does not even need to be on) for the Darknode to be migrated.

[antaeus1986]

I think the only risk from this function is that people can abuse migration. Register new accounts and using referral credits, making migration to them. In crypto community there are many "freeloaders", so you need to limit the number of migrations, for example once every 6 months, not more often (or make some other restriction)
I'm thinking about this incident .In Digital ocean, they thought that client launched a droplet for mining cryptocurrency and used referral credits
https://blog.digitalocean.com/an-update-on-last-weeks-customer-shutdown-incident/

[loongy]

Any mechanism to rate limit this feature would be easy to circumvent. We will just have to rely on the liveliness safeguards in place to discourage people from migrating in a way that causes too much downtime.

[loongy]

Closing in favour of #75. The same kind of issues that apply to #75 also apply to cross-provider migrations.