Readiness logic cannot access APIs when custom allowed origins are set

[lukashornych]

When an API has custom allowedOrigins list defined in configuration, the internal readiness logic cannot access the API, because CorsFilter cancels the request because the readiness logic doesn't send any origin header, thus it is not allowed.

We need to send origin header from the readiness logic if any allowed origin is specified.

[lukashornych]

After lots of discussion, we've come to conclusion that custom allowed origins will no longer be supported by evita, instead * wildcard will be used for Access-Control-Allow-Origin at all times. This is because:

• we support accessing all APIs through lab url and, thus we would have to dynamically merge allowedOrigins from all configs, which is lots of added complexity for feature that is not used
  • current implementation wasn't entirely correct, it required specifying same allowedOrigins for all APIs
• evitaDB is database which will be exposed only in internal network most of the times, therefore it doesn't make sense to maintain such complexity for such edge case
• more control can be added by placing nginx before evitaDB with custom CORS logic

Also the CorsFilter and CorsPreflightHandler were incorrectly implement (cause of the original issue) and were reimplemented into custom CorsService based on several resources on how a server should handle CORS for browser.