Provide method for QuarkusTestResourceLifecycleManagers to get current config values or know what profile is running

[GregJohnStewart]

Description

Lifecyfle managers can need to spin up different services in different ways for different test profiles.

Currently, the only way for the QuarkusTestResourceLifecycleManager to know how setup resources from one test to another are through initArgs. This works, but has a couple flaws:

• requires arg to be set for every test class of different profiles
• makes for very long-winded annotations, even for single flags

If QuarkusTestResourceLifecycleManager had a way to access at bare minimum what profile is currently running, or even had access to preliminary configs, it would eliminate the need for all the extra annotations.

Implementation ideas

Just throwing ideas out, but concerning the start() method;

Instead of returning values to override config, what if the start() method takes as a parameter the current configMap: start(Map<String, String> configMap). This would allow for both overrides to that map and for the manager to glean information about what profile might be running and what needs started up.

Or just add a method or member to QuarkusTestResourceLifecycleManager that takes the current config/ running test profile that makes it available to implementations.

[quarkus-bot]

/cc @geoand

[famod]

I think I've just run into a similar problem with @EnumSource; the manager would need to know which enum is selected.
OTOH this is not really related to "config", so it's a bit different.

[geoand]

I see where this is coming from, but I don't really see a way to implement it properly.

[GregJohnStewart]

If we could just get some context form what is running, say the current profile, that would work for me... I'm not read into the flow of this but I might assume that in the context of where init() for the lifecycle manager is called, the annotations of the test class are reachable, and therefore the test profile that we are currently running.

[geoand]

#22180 should provide the bare minimum for this, i.e. the QuarkusTestResourceLifecycleManager can now know the name of the profile it's running in