feat: add request limits on accept, content-type, and content-length headers

[stijnmoreels]

Adds request guards/limitation on:

• Accept header
• Content-Type header
• Content-Length header
  With user-friendly error http responses.

Closes #392

[stijnmoreels]

I tried to follow the style guidelines and way of working, please let me know if I did anything wrong. Happy to help! 👍

[TheAngryByrd]

Looks good from my end. I only have some questions that other maintainers (@dustinmoris) should weigh in on.

So far Giraffe doesn't have many error messages it returns that are hard coded. I could only find one place where we do it. I'm wary of having error messages like this hard coded for localization and even preference reasons. However I'm unsure of how to resolve this easily within this library.

[stijnmoreels]

Looks good from my end. I only have some questions that other maintainers (@dustinmoris) should weigh in on.

So far Giraffe doesn't have many error messages it returns that are hard coded. I could only find one place where we do it. I'm wary of having error messages like this hard coded for localization and even preference reasons. However I'm unsure of how to resolve this easily within this library.

Maybe we can have a different set of functions that takes in a custom error HTTP handler. There maybe needed two, as we check both on the presence of the header and whether the header has the correct value.

let haveContentTypesCustom contentTypes errorHandler = // ...

[dustinmoris]

I'd prefer to make the first parameter of each of these handlers to accept an error handler. It's not just about changing the message, but the entire response should be flexible. For example an API could return this as a JSON object or plain text response but a website might want to render a HTML page with the error displayed.

Here's an example of where this approach has already been taken:
https://github.com/giraffe-fsharp/Giraffe/blob/master/src/Giraffe/Negotiation.fs#L159

Of course in the final user application one would define that handler only once and then use the new handler for everything else, e.g.:

let someErrorHandler = ...

let validateContentType = haveAnyContentTypes someErrorHandler contentTypes

// then use validateContentType everywhere else

[stijnmoreels]

Ok, that's fine by me! 👍 I'll change this to your needs.
Although, in the negotiation example, the exception handling (unacceptable handler) is passed not as the first parameter.

[64J0]

This feature looks pretty cool!