Set up config correctly for isolated @QuarkusMainTests

[holly-cummins]

Resolves #49780 (comment)

The fact that @QuarkusMainTests pass when combined with @QuarkusTests but fail otherwise gave the clue to the fix. The FacadeClassLoader initialises config on classloaders it creates, but if there's no @QuarkusTest, it won't create one.

In normal testing mode, the parent classloader of the FCL is the app classloader, and that gets the test config initialised on it in some other path. (I can't remember exactly where). But in continuous testing mode, the parent classloader of the FCL is a QuarkusClassLoader, for performance reasons (that classloader has already done a lot of the work of classpath resolution and loading the classes). So a natural fix is to add the test config onto that QuarkusClassLoader.

This isn't quite enough of a fix, because during test execution, in continuous testing mode, the TCCL is the FCL. If the TCCL is the FCL, that stops the config on the QuarkusClassLoader being found. The TCCL really shouldn't be the FCL, but it happens because the launcher session gets started twice in continuous testing mode. We detect that condition for Eclipse, so I've generalised the guard.

In a follow-up PR, I'd like to:

• Experiment with just detecting gradle and only setting the TCCL on launcher session opening in the gradle case
• Experiment with removing the TCCL-setting logic in AbstractJVMTestExtension, since I think I might have fixed all the cases where the TCCL comes in wrong
• Split FacadeClassLoader into two so that the continuous-testing specialisations can be in their own class. There's enough of them now that it would simplify the code.

[quarkus-bot]

Status for workflow Quarkus CI

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

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

You can consult the Develocity build scans.