improvements to caching and request queue

## Use Case

The SubscribableRequestQueue has one main API problem: you can pass different actions in under the same key and id. And there is no way for the caller to know that their action may never be invoked.

## Solution

Clean readable maintainable and understandable api's.

There isn't really an action item here apart from considering if we can re-engineer the caching and chunk fetching logic to be simpler while still handling the features we need (cancellable batches of chunk fetches, etc)

One thought experiment is to try inserting a proxy chunk in the cache before issuing the fetch. Then there is extra bookkeeping around cancellation but it might eliminate the need for the SubscribableRequestQueue.

The other idea floated in our discussion was to use a less object-oriented and more "database oriented" api and code flow.