Evaluate a two-level per-request + shared cache

[raulk]

ethql currently supports a request-scoped cache, but there is benefit to shared caching. In a production scenario, it is likely that the youngest blocks will be hottest, and that highly used smart contracts will garner higher ethql traffic.

However, there is also risk:

• Requests from client A can lead to evicting entries that are hot for client B, hence making the runtime cost of a query non-deterministic. Cache pinning is a possibility here, but how to manage the pinning is a different discussion.
• Misbehaved clients could thrash cache intentionally to degrade the performance of ethql.
• Chain reorgs can render cache entries dirty, so an eviction process is required to remove entries affected by a reorg (reorgs can be notified to us via WSS).
• In the above, if the WSS connection is dropped, we'd need to temporarily disable the cache, and start with a cleared cache once the connection is re-established.

Ultimately I see a two-level cache:

• L1 => request-scoped cache, as it's already implemented.
• L2 => shared LRU or LFU cache with different backend implementations (e.g. in memory, Redis, etc.)

[ericjuta]

Plugging this in here too in reference to #83 and the satisfying PR #91

• https://github.com/apollographql/apollo-cache-control
• https://blog.apollographql.com/easy-and-performant-graphql-over-rest-e02796993b2b
• https://blog.apollographql.com/automatic-persisted-queries-and-cdn-caching-with-apollo-server-2-0-bf42b3a313de
  The latter has a three step process about carrying out a partial e2e caching strategy which is pretty nice to start!
  @raulk

[raulk]

Thanks, @rej156. Will look into that!