ToolingApiClasspathProvider.groovy

Let ToolingApiClasspathProvider share the Kotlin DSL TAPI model package

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove play framework support from Gradle distribution

This is superseded by: https://gradle.github.io/playframework/

This commit removes:

- The `platform-play` and `ide-play` subprojects

- The documentation for the functionality provided by these projects

Remove container callback measurement feature toggle

Track task creation and execution times for listener/config callbacks

Project evaluation listener callbacks such as `afterEvaluate {}` and

configuration callbacks of domain object collections such as `all {}`

are now attributed to the plugin that registered them. Thus, the origin

plugins for tasks created in such callbacks is correctly determined and

their execution times are added to the plugin's total execution time

that is reported to TAPI progress listeners.

Report TAPI progress events for work items

This commit introduces a new `OperationType.WORK_ITEM` and adds specific

`ProgressEvent` implementations. For backwards compatibility, if the

new OperationType is not requested, but `OperationType.GENERIC` is, it

will be reported as a generic build operation.

Move cross-version test to appropriate subproject

Named classloaders (#6834)

This should help give some more context while debugging classloading issues.

Delete custom RetryRule

Fix native tooling int tests in forking mode.

Revert "Move @TargetGradleVersion and GradleVersionSpec to central integ test infrastructure, from Tooling API test infrastructure."

This reverts commit e71f77c55e865f583ff930fc29fb9c33a089f33b.

Fixed test to work with older Gradle versions.

Enable Gradle Daemon by default

Make `FilteringClassLoader` immutable

`SystemClassLoaderSpec` is moved to its own class so that it can be

included in `gradle-worker.jar`.

+review REVIEW-6020

Allow fixtures from `:ide` to be used in forked TAPI tests

Initial implementation of Tooling API performance tests

This commit introduces a new kind of performance tests, aimed at measuring the performance of the Tooling API.

By extending `AbstractToolingApiCrossVersionPerformanceTest` a test can check the performance of the tooling

API for various scenarios. In that case, you can specify:

- a list of target versions

- an action to execute in a `GradleConnection` context

The list of target versions is used to tell which version of the Tooling API to use, but also to tell which

version of Gradle we're connecting to.

For now, we're only checking the total duration of the operation, and we are reusing the `CrossVersionResultsStore` to

store the results. We do *not* check the memory consumption yet (not our initial focus).