java

Extract `WorkerSharedUserHomeScopeServices`

With the services shared between `GradleUserHomeScopeServices` and

`WorkerDaemonServices`.

Polish `WorkerDaemonServer`

- Fix formatting

Introduce `ValueSource` API

Based on the _Westline services_ prototype (#11168).

make inner classes static where possible

Signed-off-by: Steven Crockett <crockett.j.steven@gmail.com>

Rename some methods of `InstantiatorFactory`.

Add `BuildServiceParameters.None` marker type that is used to indicate that a build service does not take any parameters, to match the pattern used in other places.

Extract some validation logic from several places so it can be reused in the places where parameterized isolated objects, such as artifact transforms or build services, are registered.

Extract some reusable logic to determine the parameters type of an isolated implementation type, such as a worker API action or a build service.

Align no isolation worker with isolated workers

Move a bunch of shared project scope services to a shared provider

Ensure reused worker daemons resolve files from the correct directory

Make DefaultResourceHandler.Factory an interface we can stub out in workers

Expose ExecOperations service to workers

Expose ObjectFactory and FileSystemOperations to worker actions

Compiler daemons can access internal services

De-incubate Worker related APIs

Fix tests

Use a non-decorated fork options when creating fork options for worker daemon

WorkerDaemonClients are retained across builds, so any object associated with

it must not contain project state since this will be kept around until the worker

expires.

- Introduce a newDecoratedJavaForkOptions which creates a decorated JavaForkOptionsInternal

- Replace calls to the decorated version of the method with non-decorated versions where appropriate

Fix issue with properties object not being isolatable

Ensure that no-isolation workers run with the classloader of the submitting thread

This fixes a problem where, in a composite build, a worker can get a context

classloader set to a classloader from another project, which causes a class

mismatch when we attempt to re-hydrate a legacy runnable class in AdapterWorkAction.

We now ensure that the context classloader for no-isolation workers get set

to the context classloader of the thread that submitted the work.

Updates to upgrading guide and WorkerExecutor javadoc