Add ability to decorate resolver functions

[hlship]

A certain useful class of problems can be solved by passing field resolver functions through a set of middleware before being employed in a schema; this would allow for such things as authentication/authorization checks, implicit logging, tracing, and other common use-cases.

I would suggest a signature as follows:

 (middleware object-name field-name f) => f'

The object-name and field-name are keywords. The function is as provided in the input schema, and the result is the same or a decorated resolver function.

[hlship]

Another common use case is converting a core.async channel, or a Manifold deferred, into a Lacinia ResolverResult.

[stijnopheide]

Maybe middleware (as in ring middleware) is a bad name. Since results of resolver functions can be asynchronous would it not be better to use interceptor like in pedestal / yada?

Related to that, how would a user define an interceptor that also can handle async results of the resolver function f?

[hlship]

Want to keep whatever we do very, very simple. A function that decorates a raw resolver function into a smarter resolver function would do the trick. There's nothing that says you can't use an interceptor as part of the implementation of your field resolver, but we want to avoid too much machinery or magic (and there's already a bit!).

[stijnopheide]

this is really good! thank you.

[heneryville]

This was removed in #85 . Presumably b/c the same work can be done by transforming the input to attach-resolvers in application code.

[hlship]

Absolutely, though in the current alpha release there's some support for decorating functions based on the presence of directives on the field.