Make test resource config override dev service config and system props

[holly-cummins]

Resolves #48784

After the big test classloading rewrite, ephemeral ports for the lambda dev service stopped working (that is, if a user sets the port as 0 in application.properties, in hopes that they get a randomly assigned one, injected clients will attempt to connect to a port "0"). This issue would also affect other services where a user explicitly configured a port of 0. To fix that, the dev service needs to be moved to the new model, but that's not enough. The lazy config source that knows the random port needs to have a higher priority than the '0' hardcoded in the application properties.

Fixing this is (almost) a straightforward matter of bumping the priority (ordinal) to something 400 or higher. Sadly that simple fix creates a ripple of other problems:

• The MultiClientImportPreloadingTest in the redis-client test suite uses a TestResource to start and stop a redis instance, but the test doesn't disable dev services, so there are actually two redis instances. (I've checked, and this is the case even on 3.21.) For some of the test to pass, they needs to connect to the test resource one, not the dev service one, and for that to work, the dev services config needs to be lower priority than application properties. Arguably, this is a slightly silly test for starting things twice, but I don't want to regress behaviour that currently works.
• The KakfaCompanionResource test resource used by the integration-tests/reactive-messaging-hibernate-orm and integration-tests/opentelemetry-reactive-messaging tests interacts with the dev services, and for it to work, test resources need to have a higher priority than dev services
• The random (ie ephemeral) port test in extensions/resteasy-classic/resteasy-client uses a QuarkusUnitTest.overrideConfigKey to configure the port to 0. QuarkusUnitTest.overrideConfigKey uses the same RuntimeOverrideConfigSource config source as test resources do. For this test to pass, unit test sources need to have a lower priority than dev service sources.

So we have the following desired behaviours:

• Config for test resources should have a lower priority than system properties, but higher than dynamic dev service config.
• Config for QuarkusUnitTest().overrideConfigKey should have a lower priority than dynamic dev services config
• Config from dev services should be higher than system properties (or -Dservice.port=0 wouldn't work).
• Config from dev services should be lower than application properties (or coexistence with test resources wouldn't work).

As a hierarchy of priorities, that would be (from highest to lowest):

• Dev services 'overrides', such as replacing "0" with an ephemeral port
• System properties
• TestResourceManager.start [currently the same as QuarkusUnitTest]
• QuarkusUnitTest.overrideConfigKey [currently the same as TestResourceManager]
• Application properties
• Dev services 'filling in the blanks' config, such as defining a service port where there wasn't one before

So I see two options. One is to split the RuntimeOverrideConfigSource into two so it can have two priorities for the two different scenarios, and the other is to split the dev service source into an 'underride' and 'override' pair. I worried that I might keep finding scenarios where the test resource config wasn't quite at the right relative priority, whereas the "this should override" vs "this should not override" distinction for dev services seemed clearer. So I went that way.

It should be really clean to just say 'only have this as an override if the same property is found in the original, user-defined, config' but getting that list wasn't so easy, and passing in the hardcoded config just made the API really confusing. I wondered about using ConfigUtils.isPropertyNonEmpty(propName) but that would be introducing the same problem of fighting with test resource overrides, but with some extra sequencing fun.

As part of this, I also had to make the port a runtime config element. Otherwise, CI was green, but there was a warning in the logs.

[github-actions]

🎊 PR Preview 99c1f2e has been successfully built and deployed to https://quarkus-pr-main-48815-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit c39886d.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

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

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	Native Tests - Windows support	Build	Failures	Logs	Raw logs	🔍

You can consult the Develocity build scans.

Failures

⚙️ Native Tests - Windows support #

- Failing: integration-tests/liquibase 

📦 integration-tests/liquibase

✖ Failed to execute goal io.quarkus:quarkus-maven-plugin:999-SNAPSHOT:build (default) on project quarkus-integration-test-liquibase: Failed to build quarkus application

[holly-cummins]

I can see the windows native liquibase failure in other runs (such as https://github.com/quarkusio/quarkus/actions/runs/16332365795/job/46138054967), so I'm confident it's not caused by this change.