Better toleration of `junit-platform.properties` in user code

[holly-cummins]

As discussed in #47646, the recent classloader changes introduced a break where if user code has a junit-platform.properties file, tests can't start.

However, even after fixing that, there are some more subtle problems caused by junit-platform.properties in user code.

There are two basic scenarios:

• Quarkus properties get loaded first. User properties are not honoured.
• User properties get loaded first. Quarkus properties are not honoured.

Scenario: Quarkus properties win

If the Quarkus properties win, it's hard for users to get their properties honoured. We used to have an isolated properties file (introduced in #22172), so that the whole module could be removed. #42715 removed that, and replaced it with a model where users could configure the order using Quarkus config. #47646 suggests users may still sometimes have junit-platform.properties files.

Another, simpler, mechanism for users to get their properties honoured is to set them as system properties.

Scenario: User properties win

In this case, two pieces of Quarkus function stop working:

• We don't order tests. That used to mean extra startups if there were profiles and resources, but post test-classloading-rewrite, some tests could stop working entirely.
• It's not possible to retrofit @QuarkusTest annotations to existing tests using the service loader mechanism.

Options for fixes

• Detect the case where multiple files are present and print a warning giving users instructions to pass properties as system config. This should be fairly easy, although identifying which set of properties win so we can give the right instructions might be harder.
• Re-introduce the junit-properties module. This allows users to exclude our properties, but I'm not sure it's not as simple for them to just set their properties using system properties as to do an exclude in their pom.xml, especially since they shouldn't be using junit-platform.properties for class order anyway
• Fix Support multiple junit-platform.properties on the classpath junit-team/junit-framework#2794. This would, of course, be the ideal.

[quarkus-bot]

/cc @geoand (testing)

[dankristensen]

Have just upgraded from 3.20.2.2 to 3.26.4.

So as i understand this, the only workaround is to remove my custom junit-platform.properties file for now?.