DefaultVersionedComponentChooserTest.groovy

The `ArtifactTransformDependenciesProvider`is now made available through

`Transformation.transform` and `TransformerInvoker.invoke` instead of

being part of the `TransformationSubject`.

The motivation is that this type provides context for all transforms,

while the subject is transform step specific.

Issue #7766

This commit fixes an issue with content filtering, which led to versions

being silently ignored because we were listing versions, _then_ filtering.

Instead, this commit makes sure we actually only return versions which

do participate in the repository.

This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector`

classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has

the advantage that we can reduce the use of the module identifier factory, which is called very

often during dependency resolution. Sharing instances reduces the need for conversions, and makes

comparisons faster.

Extract interface and two implementations

Without this change, it is not possible to know which versions Gradle

considered for a dynamic range, unless it's rejected by a rule or by

attribute matching.

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

This commit collects all rejections during dependency resolution,

so that we can properly show them in the dependency insight report.

This highlights some consistency/readability issues, like when a

rejection originates from a constraint. For this reason this commit

does **not** pass tests, and is just the first step towards better

rendering.

This gives us better abilities to unit test the behavior of this specific

rule executor.

This means that passed in parameters must be snapshotable as defined by

the ValueSnapshotter

Added support for Attribute to ValueSnapshotter

This commit improves rendering of errors in case resolution fails because

all versions in a dynamic range are evicted, and that at least one of the

evicted versions was evicted because of attribute matching. The error will

now report the attributes on each tested version, as well as the requested

attributes.

For this, the module not found exception has been updated to carry more

context, and now makes use of the tree formatter for consistency with other

exceptions in the codebase.

The version parser is by far the largest contributor to garbage created during the

resolution of a large dependency graph. This commit creates a build scope version

parser which is shared and caches the result of parsing, avoiding the creation of

a significant number of arrays.

This commit adds support for matching the component attributes during the selection

of a version, when the selector is dynamic. Before, component-level attributes were

ignored, meaning we could select a version which wouldn't have any variant matching

the consumer attributes. With those changes, it is possible, for example, to have

a version, 1.3, which doesn't match the consumer attributes, and an earlier version,

say 1.2, which does. In that case, 1.2 would be selected instead of 1.3.

The consequence of this change is that we now have to fetch metadata for components

that are selected during dynamic version selection, in order to check if they match

the component attributes. This used to be the case for status selectors (`latest.release`)

but not for version ranges (`[1.0, )`).

It's also worth noting that if the selector is dynamic, we will perform attribute

matching at least twice (possibly with different attribute sets):

- once during version selection (for each candidate, check if its attribute match)

- then once during _variant_ selection (in which case each variant may have additional

attributes)

When resolving a component selector to a component identifier, we now construct

a unified 'allRejects' constraint that allows the correct resolution of

dynamic versions. If all versions matching a dynamic version are rejected,

then the highest rejected version is chosen. Checking for rejected versions

in the resolved graph is done in a subsequent step, after conflict resolution.

When the set of reject constraints changes there may be a need to re-resolve

a particular component selector. Efforts are made to reduce these situations

by comparing the previously resolved version to the updated set of constraints.

Use `ComponentIdentifier getId()`

Use `ModuleVersionIdentifier getModuleVersionId()`