Gradle

Initializing a GregorianCalendar is expensive and GUtil is used

in the CLI client, so we want to keep its init time small.

The CLI, Daemon and Tooling API all share certain global services.

But when the CLI is just forwarding the build request to the daemon

(which is the default), we don't need most of these services. This

change splits the global services into a basic part (that the CLI

always needs) and an extended part (that it only needs in --no-daemon

mode). This greatly speeds up startup for the default case, because we

do less class loading, less instantiation and less service lookups.

Tasks for an included build are preemptively scheduled when they

are discovered while building the task graph. However certain dependencies

(such as compileOnly) may be discovered after the build has commenced.

In these cases, the included build will be invoked again, resulting in

multiple executions of the same included build. This test demonstrates

this scenario.

Waiting the included build execution to complete had a number of issues:

- It was not possible to assign the correct failure to a particular task

- Race condition setting the 'complete' flag for a task in time for

the graph requesting this status

Using a listener to track the status of the included build execution

eliminates these issues.

- Compose methods

- DRY

In other words, even `integTest` can have test classes running concurrently, because of `maxParallleForks`.

This commit introduces a new task, `integTestPrepare`, which is executed before any other Play! integration test

and will populate the Gradle cache found in the integration test home directory with dependencies used by the

integration tests. This should prevent some flakiness in those tests, which tend to timeout because they all try

to download the Scala compiler and its family. While it's in general not an issue, the problem is that the

collection of artifacts to be download is quite large, so cross-process locking may reach the 60s timeout. To

prevent this from happening, we forcefully execute a dummy test during the `integTestPrepare` execution, which

will trigger downloading of dependencies. This test is alone, and will be executed serially before the integration

tests run concurrently in `parallelIntegTest`.