Simplify the dev services model

[ozangunalp]

Rebased on #47610 and still very much a draft

This targets ironing out issues from #47610 and provide a cleaner model for development of extensions providing dev services.

Instead of overloading the DevServicesResultBuildItem for discovered and to be started services, this PR creates a DevServicesRequestBuildItem. A dev services request defines, the name, the build-time config (for identification), how to start the dev service (supplier of startable), and how to extract the configuration to be injected to the app (key/supplier map).

Extensions can discover running services via ContainerLocator and CompseLocator and produce DevServicesResultBuildItem or, when they need to create a service, produce DevServicesRequestBuildItem.

Changes :

• Rename RunningDevServicesTracker to RunningDevServicesRegistry.
• Dev service config providers are done via a regular Map interface implemented by a supplier map.
• Removed RunnableDevService and moved the start/reuse logic to the DevServicesRegistryBuildItem.
• Registry handles a parent-first cross-classloader type RunningService instead of Closeable. -> see below
• Neither DevServicesRegistryBuildItem nor DevServicesRequestBuildItem hold any state. All state is in the registry and RunningServices it holds.

Fixes with still some problems :

• Fixes the issue in Dev UI listing of dev services when services needs to be switched. But it is not ideal. The whole service description thing needs to be seen again. This was the reason I had to introduce the RunningService.
• Services start concurrently on forkjoin pool
• For making the log suppressors work, I added an ugly fix to delay the completion of build time logging after the start of services. Otherwise, we start services when build time logging is completed and runtime logging is not yet started, and there are no handlers to log (and therefore suppress) the logs.

Open for discussion :
For a given DevServiceOwner, do we need to hold a bunch of services or just one ? Having one would simplify things further, ex. we can remove service directly by its owner.

Edit: Fixes #47627

[github-actions]

🎊 PR Preview 1a01fee has been successfully built and deployed to https://quarkus-pr-main-48445-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.

[gsmet]

Quick question: does it handle the shared network config centrally? This has been quite a problem until now where we have to handle it specifically for every container (and implement it differently for each obviously :)).

[holly-cummins]

This comment needs updating

[holly-cummins]

Suggested change

	* BuildItem for discoevered (running) or to be started dev services.
	* BuildItem for discovered (running) or to be started dev services.

[holly-cummins]

I think these comments are stale?

[quarkus-bot]

Status for workflow Quarkus Documentation CI

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

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

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✔️	JVM Tests - JDK 17			Logs	Raw logs	🚧
✖	JVM Tests - JDK 21	Build	Failures	Logs	Raw logs	🚧

Full information is available in the Build summary check run.
You can consult the Develocity build scans.

Failures

⚙️ JVM Tests - JDK 21 #

- Failing: devtools/cli 

📦 devtools/cli

✖ io.quarkus.cli.config.SetConfigTest.addEncryptedConfiguration line 74 - History - More details - Source on GitHub

java.lang.RuntimeException: java.lang.NegativeArraySizeException: -98
	at io.smallrye.config.crypto.AESGCMNoPaddingSecretKeysHandler.decode(AESGCMNoPaddingSecretKeysHandler.java:44)
	at io.smallrye.config.ExpressionConfigSourceInterceptor$1.accept(ExpressionConfigSourceInterceptor.java:79)
	at io.smallrye.config.ExpressionConfigSourceInterceptor$1.accept(ExpressionConfigSourceInterceptor.java:71)
	at io.smallrye.common.expression.ExpressionNode.emit(ExpressionNode.java:22)
	at io.smallrye.common.expression.Expression.evaluateException(Expression.java:56)
	at io.smallrye.common.expression.Expression.evaluate(Expression.java:70)
	at io.smallrye.config.ExpressionConfigSourceInterceptor.getValue(ExpressionConfigSourceInterceptor.java:71)

[holly-cummins]

The failure seems to be a pre-existing one:

[geoand]

Just as an FYI, this change broke binary compatibility. I noticed this as Quarkus LangChain4j started failing, but I was unable to find the problem until now - the problem stems from https://github.com/quarkiverse/quarkus-wiremock/blob/dd0b21d3679cbd3f86d6b73026b2754c716364b4/deployment/src/main/java/io/quarkiverse/wiremock/devservice/WireMockServerProcessor.java#L84

[ozangunalp]

That's my bad. I suggest I prepare a PR to reintroduce that constructor.

[geoand]

No problem at all. We can (and probably should) reintroduce that contructor, but that will create a source incompatibility (which admitedly is a smaller problem)

[ozangunalp]

At least we can still get it in for 3.25

[geoand]

👌

[holly-cummins]

Just as an FYI, this change broke binary compatibility. I noticed this as Quarkus LangChain4j started failing, but I was unable to find the problem until now - the problem stems from https://github.com/quarkiverse/quarkus-wiremock/blob/dd0b21d3679cbd3f86d6b73026b2754c716364b4/deployment/src/main/java/io/quarkiverse/wiremock/devservice/WireMockServerProcessor.java#L84

Once again, I'm reminded that I really need to do the thing on the ecosystem CI that lists the commits that went in since the last green build. It might have made the detective work a bit easier.