Support p2p messaging client<->ROFL

[matevz]

To support interactive applications such as real-time gaming, chatting, AI apps (video, voice analysis), streaming the response time is important and the in-memory storage suffices, because it only behaves as cache. There are a few options for the client (browser, CLI service, MetaMask) to communicate with ROFLs currently, but each has some drawbacks:

1. Store the message on-chain (Sapphire), let ROFL regularly check the state and respond accordingly:
   • PROS: the blockchain state is the ground truth always consistent regardless of the number of ROFL instances, permanent storage, builtin spam protection (gas)
   • CONS: requires gas, slow (at least 1 block), requires EVM tooling
2. Let ROFL connect to HTTP(S) proxy and let clients communicate with it directly
   • PROS: instant communication, free
   • CONS: need to set up a (web2) centralized proxy

Proposal:

1. Implement a gRPC call for sending p2p message to a specific ROFL App Id + instance.
2. Implement a gRPC call for getting currently active instances for the ROFL App ID (is this already implemented?)

Considerations:

1. spam protection
   Since the calls are free, we need a mechanism to prevent flooding the network with p2p messages.
2. EVM compatibility
   Should we wrap the gRPC calls above into an EVM-compatible subcall? This would allow MetaMask signing the query, if needed.
3. ROFL<->ROFL communication
   If the client communicates only with a single instance of ROFL, there needs to be a way for ROFLs to sync their state via p2p. Should we use the same messaging mechanism?