Epic: Queuing, caching, and load balancing

[egasimus]

• Multiple RPC calls in parallel can overload the node
• Multiple RPC calls sequentially can be slow
• Specifying sequential/parallel complicates the API
• Implementations of some operations may consist of multiple RPC calls under the hood, depending on chain
• Some of the data does not change and can be cached indefinitely
• Some of the data can be cached until the block height increments
• The same data can be accessed through multiple RPC endpoints ran by independent parties
• RPC calls may be initiated while other RPC calls are still pending

An internal queuing/caching/load balancing mechanism could address all of the above, providing robust and performant RPC operation.

[egasimus]

The first step would be connecting to the WebSocket (https://github.com/hackbg/fadroma/issues/228). This would let us know when to invalidate block-specific data.