Spring Add Reactive CORS support

This is a draft PR not ready yet to be merged, only here for review and discussion.

It implements CORS support by creating reactive version of Spring Web and Spring MVC CORS support classes: - I chose to keep the same class names, but in reactive package. - CorsConfiguration is not tied to Servlet API so we can reuse it - CORS HandlerMapping integration is done at AbstractHandlerMapping level. Since we can't add dynamically filters CorsProcessor#processRequest()is directly called. -AbstractUrlHandlerMappingandAbstractHandlerMethodMappinghave been slightly modified to callAbstractHandlerMapping#processCorsRequest()- Only support for global CORS configuration has been implemented,@CrossOrigin` support will come with another commit.

Could you make a quick high-level overview of this PR @rstoyanchev, before I go further?

Comment From: rstoyanchev

@sdeleuze some initial comments. - I don't think the two cors packages (servlet and reactive) need to be co-located. I haven't checked for package cycles but the dependency from the web.cors on web.server is a bit bothersome. We did not have web.server before the reactive support. I'd be in favor of just having web.cors.reactive become web.server.cors where it fits better with the reactive support. - For consistency I would prefer that both CorsConfigurationSource and CorsProcessor take ServerWebExchange even if at present we may be able to get by. - The Mono<Boolean> return value on CorsProcessor is quite surprising. It seems to come down to the writeWith(Mono.empty() at the end (shouldn't that be setComplete() btw?) I would rather see the CorsProcessor only updating headers and returning a plain boolean leaving it to the caller to call setComplete. - As a follow-up on the last point, shouldn't AbstractHandlerMapping be checking the return value from processRequest and returning a NoOpHandler if the CORS check failed?

Comment From: rstoyanchev

On second thought maybe web.cors.reactive is the way it should be with web.server being a low level package mostly depending on web.http and other packages under web (e.g. cors, bind, etc) in turn depending on web.server.

Comment From: sdeleuze

I have updated the commit based on your feedback. I also made some fixes that allows CORS support to work also on Reactor and RxNetty (see Fix RxNetty/ReactorServerHttpRequest URI handlingcommit).

I am now going to work on @CrossOrigin support.

Comment From: sdeleuze

I think this PR is now ready to be reviewed before a merge on master, it now contains support for @CrossOrigin.

Comment From: rstoyanchev

I've processed the PR applying some improvements such as re-ordering of fields and methods, test improvements, and I've also created a getHandler method at the AbstractHandlerMapping level that drives the CORS checks.