Improve dataloader

[patrick91]

Here's some tasks I didn't do while implementing dataloaders:

• Custom caching
• Priming/Clearing cache
• Batch schedule function
• implement load_many

And maybe some more error checking :)

Everything is up for discussion, do we need all of them? Do we need more? :)

[AndrewIngram]

I'm wondering if the first two can be tackled by simple accepting an optional init param which is an instance of something that implement the Mapping protocol, if it's not provided just default to creating a dict as things are now.

I'd even consider removing the cache bool param because I don't actually know a reason why you wouldn't want at least query-level memoization-style caching within GraphQL -- and if people really want to not have it, could always provide a simple NullCache that also implements Mapping.

[AndrewIngram]

Hm, I'm possibly oversimplifying regarding priming and clearing.

From past experience, the main use case i've had for priming is when one loader affects another. So if I had a User type and there's userByIdLoader and a userByUsernameLoader; once one of them successfully loads a batch of users, it should have enough information to be able to prime the other for those same users.

The catch here is that you can't actually do this until the futures/promises have resolved to a value, so to avoid changing the typing of the cache (which maps to a Future) it might be necessary to wrap the resolved value in an already-resolved Future somehow (is this possible)? The alternative is to make the typing of the cache more complex, less desirable?

I guess another question here is about whether memoising so that two calls to load(1) both return the same Future within a query, is the same problem as more generalised caching.