Backend realm migration strategy

[thehowl]

As we're coming close to Gophercon, we have to be ready for the possibility of having to implement some late last-minute fixes on the backend realm.

So I propose the following for a good system to plan for future realm migration, which could pave the way for future migrations in the gno ecosystem.

• We add a new Migrate(password, newRealm string) RealmState function.
• This function accepts a password, whose value will be stored as a SHA256 hash within the repository.
• If Migrate is called with a correct password, matching the predetermined value in the package, the transaction succeeds.
  • All the variables of the realm are packed into the RealmState struct.
  • The newRealm value is stored.
  • All function calls and transactions to the realm panic, with a special message panic("Realm-Upgrade: $newRealm").
• We update the realm path in the frontend.

The new, upgraded package calls Migrate() in it, and builds its initial realm state on the data of RealmState.

[moul]

I recommend using std.GetOrigCaller() to check against a fixed admin mnemonic, rather than relying on a password.

[moul]

Your migration strategy is insightful and thorough. However, I'd like to propose an alternative: distinguishing games from the leaderboard.

By doing so, each game or set of games can have its distinct realm. The leaderboard realm can then aggregate results from these individual game realms. This approach might streamline our system and minimize potential issues.