Migrate Elytron Security extensions from config classes to @ConfigMapping

[michalvavrik]

Following extensions fits criteria for migration of security extensions from config classes to the @ConfigMapping, they are not used by Quarkiverse extensions and if users are injecting these config clasess, it must be very edge case (because I can't think of reasons it's needed after inspecting their reference guides):

• https://mvnrepository.com/artifact/io.quarkus/quarkus-elytron-security-jdbc/usages
• https://mvnrepository.com/artifact/io.quarkus/quarkus-elytron-security-ldap/usages
• https://mvnrepository.com/artifact/io.quarkus/quarkus-elytron-security-oauth2/usages

Situation is more complex with the Elytron Security Properties File extension, it is used by Quarkiverse extensions, Kogito and Camel:

• https://mvnrepository.com/artifact/io.quarkus/quarkus-elytron-security-properties-file/usages?p=1

However it is used for integration and unit testing and they are not working with config classes there. For usages, I've cloned open source code and checked following projects:

• [email protected]:quarkiverse/quarkus-microprofile.git
• [email protected]:kiegroup/kogito-runtimes.git
• [email protected]:kiegroup/process-migration-service.git
• [email protected]:kiegroup/kogito-quickstarts.git
• [email protected]:kiegroup/kogito-examples.git
• [email protected]:quarkiverse/quarkus-cxf.git
• [email protected]:apache/camel-quarkus.git

Implementation note: @ConfigMappings are passed to recorded methods instead of config sub-classes due to #39431

PR note: feel free to squash the commits, I thought it would be better to separate commits in case we detect any issue with one of migrations

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 9678bc5.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.