Daemon auto-provisioning downloads toolchain from provided url

[vmadalin]

Context

The Daemon toolchain auto-provisioning mechanism is part of Phase 2 of toolchain support for Gradle Daemon, where the motivation behind it and other technical details can be found on the public spec document. This
PR adds the capability for the auto-provisioning mechanism to download the toolchain given the specified url on the gradle/gradle-daemon-jvm.properties, supporting as well local files.

Here is the summary about the changes:

• Reuse SecureFileDownloader from resources-http on the Launcher by creating an abstraction for SecureFileDownloader.createExternalResource called ExternalResourceFactory allowing to have two different implementations for daemon and tasks toolchain, since this last one is using many services outside of the scope of the Launcher
• Moved JavaToolchainQueryService and its dependencies from toolchain-jvm to toolchain-jvm-shared so it can be reused from the launcher
• Scope JavaToolchainQueryService at a higher level #24353
  • This was marked as Global and Project for now since it requires a major refactor to keep just Global, allowing to reuse this from the Launcher. The same approach has been taken for FileResourceListener where EventScope now allows an array of scopes similar to ServiceScope to be able to support FileResourceConnector for local file urls
  • This allowed to remove the DaemonJavaToolchainQueryService implementation by reusing the JavaToolchainQueryService from the Launcher
• Created a new JavaToolchainSpec called DaemonJvmToolchainSpec allowing to create it based on PropertyFactory which is available on the Launcher. This is required for JavaToolchainQueryService.findMatchingToolchain
• Use ProgressLoggerFactory to display the downloading progress for the toolchain
• Use HttpResourceAccessor instead of UrlExternalResource since the last one doesn’t return the metadata containing the file name
• AbstractProgressLoggingHandler.ProgressLoggingInputStream moved to separate file so it can be reused
• Add more generic listener called ProgressLoggingInputSteamListener to ProgressLoggingInputStream to capture read operation progress instead of build specific ResourceOperation
• Implemented ToolchainDownloadProgressListener which is responsible for sending proper everts to display downloading toolchain progress on the CLI and TAPI:
  • Important the DefaultToolingImplementationLoader was modified to include Download progress related events for TAPI since this was causing them to be ignored due to classloader conflict causing for DefaultFileDownloadStartEvent:

CastException: Cannot cast object 'Download https://cdn.azul.com/zulu/bin/zulu19.32.13-ca-jdk19.0.2-macosx_aarch64.zip started' with class 'org.gradle.tooling.events.download.internal.DefaultFileDownloadStartEvent' to class 'org.gradle.tooling.events.download.internal.DefaultFileDownloadStartEvent'

Cause: loader constraint violation: when resolving method 'void org.gradle.tooling.events.download.internal.DefaultFileDownloadOperationDescriptor.<init>(java.lang.String, java.net.URI, org.gradle.tooling.events.OperationDescriptor)' the class loader org.gradle.internal.classloader.VisitableURLClassLoader @67ad0239 of the current class,

NOTE: This change was built on top of #29022 to avoid merge conflicts.

Tests

• DaemonJavaToolchainProvisioningServiceTest.groovy
• DaemonToolchainExternalResourceFactoryTest.groovy
• DaemonJvmToolchainSpecTest.groovy
• JavaToolchainHttpRedirectVerifierFactoryTest.groovy
• ProgressLoggingInputStreamTest.groovy
• ToolchainDownloadProgressListenerTest.groovy
• ToolchainExternalResourceAccessorTest.groovy

Demo

Simple demo exposing how auto-provisioning mechanism download the daemon toolchain from the specified url or from a local file. Note that the error is because of missing installation part, which will be addressed separately

• CLI

Daemon.toolchain.downloaded.by.auto-provisioning.mechanism.mov

• TAPI

Screen.Recording.2024-05-28.at.15.28.54.mov

Contributor Checklist

• Review Contribution Guidelines
• Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
• Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
• Provide unit tests (under <subproject>/src/test) to verify logic
• Update User Guide, DSL Reference, and Javadoc for public-facing changes
• Ensure that tests pass sanity check: ./gradlew sanityCheck
• Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

[gitstream-cm]

There are new TODOs present in this change. Should any be removed?

[gitstream-cm]

Change Summary

This PR is 75.98% new code.

Platform	Added Lines	% of Total Line Changes	Deleted Lines	% of Total Line Changes	Files Changed	% of Total Files Changed
bt_ge_build_cache	0	0%	0	0%	0	0%
build_infrastructure	0	0%	0	0%	0	0%
core_configuration	0	0%	0	0%	0	0%
core_execution	1499	54.63%	435	15.85%	51	49.51%
core_runtime	1499	54.63%	435	15.85%	51	49.51%
documentation	0	0%	0	0%	0	0%
extensibility	0	0%	0	0%	0	0%
gradle_enterprise	0	0%	0	0%	0	0%
ide	0	0%	0	0%	0	0%
jvm	414	15.09%	164	5.98%	40	38.83%
kotlin_dsl	0	0%	0	0%	0	0%
release_coordination	0	0%	0	0%	0	0%
software	153	5.58%	49	1.79%	8	7.77%

[bot-gradle]

The following builds have failed:

• All Performance Tests for Ready for Nightly (Trigger)
  • Build Scan

[ljacomet]

@bot-gradle test PT

[bot-gradle]

The following builds have failed:

• All Performance Tests for Ready for Nightly (Trigger)
  • Build Scan