Implemented CORS header handler middleware

[k-nasa]

Description

Implemented CORS header handler middleware.

Motivation and Context

close: #215

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[yoshuawuyts]

Small nit, but this is really good!

[prasannavl]

Thanks @k-nasa!

A few more bits:

• One of the reasons I layed down the current differences in implementation here (Implement a way to handle CORS headers #215 (comment)) was to help deciding which way to approach from.
• If we just want to start without validations, then I think it makes sense to start with this implementation. However I think we should leave out the features that don't make sense without proper validations entirely rather than try to cover them partially which ends up in unexpected or confusing behaviour.
• Any lack in feature set of the middleware during the initial phases, can always easily be compensated by directly adding the headers.

[prasannavl]

Looks great now! A few trivial bits.

[k-nasa]

@yoshuawuyts @prasannavl I fixed all! Please re review 🙇

[yoshuawuyts]

This is looking really good!

[fairingrey]

Looks great, thanks for your contribution! 👍

[prasannavl]

Okay, so just went through the spec - while many production cases are likely constrained to single origin where should work, I think this is impossible to get right for without validation for atleast origin to support the case of multiple origins.

• Anything other than a single origin, we need to validate and send back the current one only or fail with 400 or 401.
• When the requests have credentials, or when allow-credentials is true, origin of * will fail according to the spec.

Given this, I think the simplest way to make this work is to add origin validation to each and get the input instead as an enum Origin of Any, Exact(String/HeaderValue) or List([String]/[HeaderValue]) and then validate the origin on each request matching on the these, and sending back the actual origin directly for the Any case or sending the matched origin case otherwise, or fail with 400/401.

Alternatively, we need to parse the string header, and do the classification manually which looks a bit fragile, even though it's likely just a split on , (comma). With the enum route, we can even expand it later to support regexes or wildcarded subdomains. Ideally, we probably need to do this with a builder pattern, say CorsBuilder and get the middleware out of it, but we could do this later.

Approaching from this route, I think if a simple origin check can be done as above, we'll have a fully working middleware and we can slowly expand it to more sophisticated server side validations similar to the actix middleware.

@k-nasa - let me know if this some thing you'd like to do!

/cc @gruberb

[k-nasa]

@prasannavl I think it's good! A lot of things to do!

[k-nasa]

Should these extensions be done with this PR?

[yoshuawuyts]

LGTM

All outstanding issues have been addressed!

[yoshuawuyts]

I say we go ahead and merge this! -- thanks heaps @k-nasa!