CSRF extension breaks applications due to required config

[FroMage]

CSRF, after #34555 got merged, now requires a config value which should have a default, thus breaking the Quarkus tenet that importing an extension should not break an application by requiring things that have proper defaults.

As such, it breaks every extension user, even if they're not using headers for CSRF, so that's pretty serious.

[quarkus-bot]

/cc @pedroigor (bearer-token), @sberyozkin (bearer-token,jwt,security)

[geoand]

We should definitely have some kind of test for this...

@FroMage are you planning on addressing this issue?

[sberyozkin]

@FroMage Can you clarify please ? What exactly is broken ?

[sberyozkin]

@FroMage Or yeah, I'll just make it optional, tokenHeader - it is on main only so we have time to fix

[sberyozkin]

@FroMage Sigh, the whole optional tokenHeader discussion is back, I've re-opened it at #34555.

One thing that I don't think we can do is to add support for the header at the cost of dropping support for the hidden form fields - which will happen if we have a default header value. Supporting the internal fields for HTML form requests is essential.

[sberyozkin]

@FroMage Ignore me please, just configuring the default header value does not mean it will be present, should be a simple fix

[sberyozkin]

@FroMage This is fixed, see the linked PR, I now recall that this property was originally optional and hence I had it configured, then we agreed it should not be optional but I forgot to remove the test configuration which is why I missed that it had no default value...