Parser middleware

When parsing a query in om.next we found that it is very useful to add functionality before and after parsing the query. Such as authenticating the user, making sure actions are logged and timed for performance, deduping the query, etc.

Since the om.next parser is just a function that takes [env query] and is initialized with read and mutate functions taking [env key params], it's very easy to just wrap these functions. After having wrapped the parser function and read/mutate functions multiple times, they started reminding us of "middleware" which is often referred to as the functions wrapped around routes. We ran in to a problem with these wrapped functions when we wanted to run the parsing of keys in parallel. We never did, but we thought about writing these parsing middlewares as interceptors from pedestal.

Interceptors provide a before and an after function, that can be composed individually makes it easy to run the "before pipeline", then call the actual handler, then the "after pipeline". These 3 separate steps can easily be parallelized. We had other problems in our startup, so we never did the optimization.