Make Snaps fully event-based

[rekmarks]

Currently, Snaps do not export anything, and communicate with the outside world by passing an RPC handler function to wallet.registerRpcMessageHandler. Their lifecycle is tied to this RPC message handler function, which is invoked every time the Snap receives some message.

Rather than being plain scripts, we have decided that Snaps should export their RPC message handler function, which will be analogous to C's int main(). This handler function will be invoked every time the Snap receives a message, which may be RPC calls from external entities, or requests or events emitted from MetaMask itself. With the exception of talking to the network, the Snap will only be able to communicate with non-MetaMask subjects by returning values from its main function.

With this refactor, Snaps will be event-driven both as a practical matter and in the structure of their code. The main function will receive an extensible object parameter, and will offer a more ergonomic developer experience for Snaps developers as opposed to the alternative. (Namely, slapping different functions onto the wallet object whenever we want to add a new message type.)

Completing this refactor will entail:

• Defining the type of the main function and its parameter
• Getting a reference to the Snap's main function once Compartment.evaluate() is called
• Binding lifecycle management to the Snap's main function

[rekmarks]

For Snaps that need something like long-running workers, we may eventually introduce a concept of "workers" that are shipped as separate bundles with relaxed runtime limitations. For now, we will probably permit or openly support abusing the event-based model to facilitate long(er)-running snaps.

[ritave]

I've done some research into this previously.

• There's no practical (there are some impractical) way to just load exported functions without also running the global script environment. This means that we still have to run the Snap twice - first, using eval, to load the exports, second time to run the exported function. The logic would stay very similar to how we currently execute snaps using wallet.registerRpcMessageHandler. That's also how it's done in other projects - 1, 2
• Because of the above, and also the fact that Snap workers are ephemeral (can be killed after timeout), the global state will serve more of as a cache instead of permanent place to store data. There's actually prior use using that model, surprisingly in a Programmer Game called Screeps.
  • An explanation on how they run scripts
  • An explanation on how they do caching.
• Concerning "workers" concept - I don't think we need to have a separate API for that and we could do it completely seamlessly without the user and developer knowing - when endowment:long-running permission is encountered - the Snap would run in a special environment - a separate WebWorker with no timeouts.
• While we're talking about changing the core wallet API - it would be good to think about parallelism of Snaps. Currently multiple RPC requests can run at the same time requiring developers to know and use primitives such as async-mutex to synchronise storage reads and writes.
  • On the other hand such architecture is useful - here I'm stopping a long running RPC request using a second one.