Client middleware

[m-bock]

At work we had the following requirement: Every endpoint call with servant-client should log it's raw request and response data.

At first, it looked like this may be possible to implement with managerModifyRequest and managerModifyResponse.

However, this turned out to be not a good idea. The docs itself mention for the first function that "This function may be called more than once during request processing". And generally it was important that the logging of the request and response happens at the exact time when they orccur. And those function don't seem to give guarantees about this.

In the end our solution was roughly to create a newtype wrapper around ClientM with a custom instance for RunClient, which calls performRequest but wrapped with some middleware functions.

I wonder if there could be a way to support defining "real" middleware of type (Request -> ClientM Response) -> (Request -> ClientM Response) in servant-client.

This PR is an implementation sketch of how I'd imagine this to work. I contains a simple testcase which should clarify the main idea.

I'd be curious to hear what people think about this approach.

Note: This PR does not cover yet how errors thrown in the middleware should be handled. One way to do this would be to extend the ClientError type with a new constructor MiddlewareError SomeException.

[tchoutri]

Hi, thank you for this contribution! As this is a breaking change (adding a publicly exposed field to a record breaks pattern-matching in consumers) and not trivial addition, would you mind adding a changelog entry? :)

[m-bock]

@tchoutri
Sure, I added a changelog entry and another test which shows how errors can be thrown in the middleware.

[tchoutri]

@abailly May I ask for your opinion on this?

[abailly]

@tchoutri Sure, always happy to help but it's been a while since I have used servant in anger :)

[m-bock]

I also added a test for "chaining middleware".

[abailly]

I think this change completely makes sense and I have often wanted to have that functionality available and, as the proposer, resorted to custom ClientM or RunClient implementations for purposes that could have been well served by a ClientMiddleware like authentication, logging, etc.

I have made general suggestions which seem to make sense to me but might be inappropriate because of the coding conventions in force in the codebase, so take those with a grain of salt.

[m-bock]

@abailly
I applied all the changes that you suggested, except the one where I left a comment.
Thanks for the review!

[tchoutri]

Looks like sqlite-simple-0.4.19.0 can't be compiled with GHC 8.6.5. Since it's an obsolete version it can be safely dropped from CI.

[m-bock]

Great to see this merged, thanks for the support! @abailly @tchoutri