feature: home gnovm (chain)

[jaekwon]

Imagine black box local GnoVM you run at home. I have /r/home/emails and /r/home/messages also as realms, just stored directly in an avl tree in each realm.

• I install in my home gnovm chain a service plugin; /s/email/indexer, not /p/ or /r/ but /s/ because there's an off-chain service associated.
• /s/email/indexer reads state upon init, but also registers as a listener for notifications from /r/emails.
• when a new email comes in, /r/emails thru listeners calls /s/email/indexer.AddEmail().
• /s/email/indexer also imports /d/email/indexer which is the off-chain daemon component. It's gno code with gonative imports available only for that local machine, which runs in its own container.
• /d/email/indexer can only speak to /s/email/indexer.
• /s/email/indexer can import any /r/ or /p/ but not other /s/, and its own /d/email/indexer, unless otherwise restricted by ACL system.
• my phone registers an account with the local gnovm home chain.
• this phone account is restricted to only use /s/email/indexer.
• my phone calls /s/email/indexer, it asks /d/email/indexer which queries postgres, and returns back through /s/email/indexer.
• ACL system includes the phone account; in a basic impl it could be a toml file that is managed outside the normal gnovm execution. phone account --> restricted to /s/email/indexer and /r/email; /s/email/indexer --> restricted to /r/email; the benefit of this is that it's easy to understand and modify at any time. If the restrictions were stored in the iavl store GnoAccount we need to make sure to iterate over all of them when displaying ACL information. We could store service ACLs in the realm itself too, but it's not clear how best to make them as easy to modify as a single toml file.

The /d/email/indexer is a gno package with also go files in it, and maybe postgres is natively supported.
/d/email/indexer should be deterministic but it doesn't need to be.
/d/email/indexer should be idempotent with regards to which height it starts with, so that it doesn't matter when it's installed, the indexer reads all existing emails before receiving callbacks from /r/email; but it doesn't need to be; it could only start indexing from moment of install.

There can only be one daemon running for the chain, because it might not be deterministic.
But there could be multiple standby-daemons running, to failover-switch over to in case of failure.
If the daemon is not deterministic, the behavior upon failover switching is undetermined.