Rewrite BuildTimeRunTime and RunTime Defaults ConfigSource

[radcortez]

• Fixes Wrong warning message param order / Upstream #26156
• Fixes quarkus.tls.trust-all does not seem to be a build time property #23680
• Fixes Bootstrap config values from ConfigSourceFactory differ in continuous testing #25857

Currently, there are a few issues with the BuildTimeRunTime values and the RunTime Default values:

• The source and values are generated directly in the Config class. In Dev mode the sources are not regenerated, meaning that lookups or injections to ConfigRoot classes keep the old values. This is not an issue in most cases because these configurations are used during build time in the extensions. Still, users can observe different values (or if somewhere in the code, we look up the property directly). The case of quarkus.tls.trust-all which is marked build-time, but it can be changed during runtime.
• Do not override BUILD_AND_RUN_TIME_FIXED properties #20932 changed the BuildTime and RunTime values source to have the max original value. This prevented override of such configurations. This was not very visible because these configurations are primarily used in build time in the extensions, but users can observe different values.
• Defaults values for BuildTime and RunTime could still be overridden since the source is set with a low ordinal.
• The report of such values being overridden was inaccurate due to all of the above.

Changes in the PR:

• The BuildTime and RunTime values and the RunTime Default values are now written to an external resource. This fixes the issue with reloading values in DEV mode.
• The BuildTime and RunTime default values are now merged with the recorded user values.
• The source gets max priority to disallow overring values. This prevents users from seeing different values if they look up a configuration directly or inject a ConfigRoot class.
• The recorded RunTime Default values are now merged with the Build Item RunTime Default values
• Checking for overrides warnings takes into account the source of the configuration

A few extra considerations:

• We now instantiate the source twice (for static and runtime). There are other cases where we double instance sources. I think we can improve this generally by just reusing the builder from static to runtime.
• These sources are now a resource for the native image. We can probably still generate a class with all the values, but I wanted to keep the same code and behavior between dev and native.
• Due to being a single source now and the defaults being in higher priority, it should require fewer lookups to create the ConfigRoot classes.

[quarkus-bot]

Failing Jobs - Building 56160c0

Status	Name	Step	Failures	Logs	Raw logs
✖	JVM Tests - JDK 11	Build	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 17
✔️	JVM Tests - JDK 18

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: extensions/smallrye-reactive-messaging-amqp/deployment 
! Skipped: integration-tests/reactive-messaging-amqp 

📦 extensions/smallrye-reactive-messaging-amqp/deployment

✖ io.quarkus.smallrye.reactivemessaging.amqp.SecuredAmqpTest.test line 28 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with io.quarkus.smallrye.reactivemessaging.amqp.SecuredAmqpTest was not fulfilled within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[geoand]

👍🏼

Seems reasonable to me.

[gsmet]

@yrodiere given you had a look at the config code lately, I wonder if you could have a quick look at this one? Feel free to say no if you're not familiar at all with this code :).

[yrodiere]

@yrodiere given you had a look at the config code lately, I wonder if you could have a quick look at this one? Feel free to say no if you're not familiar at all with this code :).

I'm afraid my experience with that code is quite limited, but from that (limited) perspective, the changes look good.

In any case, replacing bytecode generation with a simple text resource will get a +1 from me anytime 😁 It's much easier to debug.