Allow CORS wildcard headers

[StaticBR]

Currently it is not possible to set wildcard header values for some CORS Headers.

This bug concerns:

• Access-Control-Allow-Headers
• Access-Control-Allow-Methods
• Access-Control-Expose-Headers

All of which can, according to the specs set to "*".
Setting this value in the quarkus properies, results in quarkus not setting the header field. This is not correct, since the default values are not "*".

This PR fixes this behavior.

[sberyozkin]

@StaticBR Can you clarify please why is it necessary ?

Quarkus would set Access-Control-Allow-Headers and Access-Control-Allow-Methods to concrete values. In your test, there are no Access-Control-Requst-Headers and Access-Control-Request-Methods.

As far as Access-Control-Exposed-Headers is concerned, it really requires a user to think and make a decision which headers should be exposable to Java scripts.

[StaticBR]

@sberyozkin
I try to explain where I am coming from:
I wanted to set the Access-Control-Expose-Headers to * in quarkus.
So i set the configuration property: quarkus.http.cors.exposed-headers=*
Which resulted in no change at all. So i searched why this configuration is not working ... which resulted in this PR.

I think that if a Developer explicitly set a configuration property to *, which is a valid value. This is what the header should be set to.

To your points:

Quarkus would set 'Access-Control-Allow-Headers' and 'Access-Control-Allow-Methods' to concrete values.

This is a suitable default. But if the config property is set, why use the default?

In your test, there are no Access-Control-Requst-Headers and Access-Control-Request-Methods.

Sorry i do not understand what you mean by that. These headers are in the test case.

As far as Access-Control-Exposed-Headers is concerned, it really requires a user to think and make a decision which headers should be exposable to Java scripts.

Yes, and if my decision is to expose all headers for an origin, I have currently no possibility to set this via the configuration property.

[sberyozkin]

@StaticBR

In your test, there are no Access-Control-Requst-Headers and Access-Control-Request-Methods.

Sorry i do not understand what you mean by that. These headers are in the test case.

Your test case has *Allow* variations in the response, but not input headers, like Access-Control-Request-Headers

which is when

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

is expected to be returned: This header is required if the preflight request contains [Access-Control-Request-Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers).

[StaticBR]

@sberyozkin
Okay, now I'm more confused. I just changed the preprocessing of the configuration property. So this change is what the test case verifies.
I did not alter under which circumstances the header is returned. So i assume this is already checked by another test.

Long story short:
What do you need, so you will be able to merge this?