Better CORS handling
Summary
LLNG 1.9 tended to respond to CORS pre-flight (OPTIONS) requests with a HTTP 200 code. I'm not sure whether or not this was on design, as I can't find any specific OPTIONS handling in 1.9 code.
In 2.0, however, OPTIONS requests always return a HTTP 400 code, which means that some installations that used to rely on the 1.9 behaviour now see errors.
A quick solution for this is to to use some web server config to forge a 200 reply.
Furthermore, there are no options to set the Access-Control-* CORS headers, forcing users to allow '*' in their web server config
Design proposition
We should probably have an option in Manager that allows a user to set the CORS headers. OIDC and REST API would be common targets for CORS requests.
Optimally, we should only allow CORS requests from registered applications (VHosts, RP, SP, CAS services). We should also generate the Access-Control-Allow-Origin header from the incoming Origin: header of CORS requests, if it matches a known domain.
Finally, CORS pre-flight requests should work and respond with a 200 code when CORS is allowed in the manager.