Generalize middlewares

Most of our middlewares could be more parametric.

• By expanding HttpRoutes with Http[F, G], the same middleware can be applied to either HttpRoutes or HttpApp.
• By expanding Http[F, G] to either Kleisli[F, Request[G], B] or Kleisli[F, A, Response[G]], middleware that only affects one side can compose with Kleislis of different outputs or inputs. The latter is particularly helpful for applying the same middleware to both regular and authorized HTTP functions.
• Increased parametricity makes it more clear what the middleware can do from the type alone.

This is a mostly mechanical translation, and would make a great first issue for anyone looking to better understand type classes and constraints. If you claim a middleware and offer to submit a PR, I will help you if you get stuck.

Server:

• AutoSlash.scala
• ChunkAggregator.scala
• CORS.scala
• CSRF.scala
• DefaultHead.scala
• EntityLimiter.scala
• GZip.scala
• HSTS.scala
• Jsonp.scala
• Logger.scala
• PushSupport.scala
• RequestLogger.scala
• ResponseLogger.scala
• Timeout.scala
• URITranslation.scala
• UrlFormLifter.scala
• VirtualHost.scala

Client:

• FollowRedirect.scala
• Logger.scala
• package.scala
• RequestLogger.scala
• ResponseLogger.scala
• Retry.scala

[rossabaker]

Alright, then I think we’re done here.

I’m very happy about the response we got. Thanks to all who jumped in. We’ll try to make better use of the first-issue tag and continue this momentum with new contributors.

[rossabaker]

On further thought, I don’t think there’s anything to do on the client in the current design. The server ones are a function of Kleisli to Kleisli, and we can be generic in any of its three parameters. A Client only has one free parameter, and we’re already polymorphic on that.

If we proceed with @ChristopherDavenport’s idea of a Client being just a Kleisli, then there’s something to do. Until then, I think we’re done here.

Am I talking nonsense?