Rewrite the CORS middleware

[jplatte]

Closes #194

Motivation

The CORS middleware could use some streamlining internally and also doesn't offer all of the functionality that people want from it.

Solution

This PR basically rewrites how the cors::ResponseFuture is built (but changes very little about how its structure and Future impl). It builds on my previous refactorings, but still amounts to a very large diff (mostly due to reorganizing how header values are obtained). It might be easier to read the new module entirely than to look at the diff

Notes

This is a work in progress, I still need to

• Add missing documentation for the new types
• Add more examples to the method documentation
• Add more constructors for the various new types (AllowOrigin, ExposeHeaders and such)
• Fix Vary header application (currently there's just a hardcoded list of headers there, which seems wrong)
• Add a new constructor that's more permissive than Cors::permissive() (potential names would be permissive_with_credentials, very_permissive, extremely_permissive, anything_goes)
• Create internal sub-modules?
• Panic if AllowCredentials::yes() is combined with Any headers / origin / ...
• Remove allow-credentials from permissive()
• Add #[must_use] to most / all of the types in the cors module
• Fix broken intra-doc links

[jplatte]

Still one last thing left to do but if CI passes there should be no more rebases (the last change will be a separate commit).

[jplatte]

Hello, #237 looks great ! I'm also waiting for this PR to solve the issue apollographql/router#792

— @bnjjj in #244 (comment)

I just wanted to highlight that this PR as-is does not change what happens when there is no origin.

I read that it's a best practice to include Vary: Origin in the response headers when there is no origin header in the request so I wanted to look into that, but I don't really get why full CORS headers should be returned to requests without an origin, because the origin header is a critical part of what makes a request a CORS request. Can you explain your use case?

[jplatte]

Well, scratch that. The origin is now no longer required for CORS stuff to be sent, since I didn't really see the downside to changing it that way and it even simplified the code.

The closure CORS settings constructors still have an origin parameter though, and will not run if there is no origin. Instead, when a closure is configured, we just don't set the corresponding header. I think this should be sufficient for all the use cases I've heard of so far, but with the new design it should be backwards-compatible to introduce a new closure variant without the origin and stuff like that anyways.

This is now finally ready for review! 🎉

[davidpdrsn]

I think this looks great! Thanks for working on it.

Wanna add a changelog entry as well?

[jplatte]

But why have only one changelog entry when you can have five? 😄

[bnjjj]

@davidpdrsn Just out of curiosity, I need this new cors middleware in Axum, do you plan to release a new version soon ?

[davidpdrsn]

I do yes. Once #250 has landed I'll prepare a release. Until then you can depend on tower-http via a git dependency.