Prefer project modules on dependency resolution per default

[fawind]

Before this PR

Every so often we run into support issues due to Gradle's version ordering semantics not being strictly compliant with our sls-version ordering.

E.g. based on the sls-spec, 1.264.0 < 1.264.0-90-g2f01179 holds true but according to Gradle's version ordering, the opposite is true, 1.264.0-90-g2f01179 < 1.264.0.

Using its default resolution strategy, Gradle will try to substitute artifacts of local projects. However this can fail when the version ordering does not align because according to Gradle's version ordering, the module is relying on a version from the future.

As a result, Gradle fails on dependency resolution which errors such as:

A problem occurred configuring root project 'my-project'.
> Could not compute lock state from configuration 'unifiedClasspath' due to unresolved dependencies:
   * project :my-sub-proj (requested: 'project :my-sub-proj' because: requested)
        Failures:
           - Could not resolve project :my-sub-proj.
           - Unable to find a variant of com.palantir.my-sub-proj:1.264.0 providing the requested capability gcv:path=:my-sub-proj scope=PRODUCTION:0:
     - Variant compile provides com.palantir:my-sub-proj:1.264.0
     - Variant runtime provides com.palantir:my-sub-proj:1.264.0
     [...]

After this PR

Prefer project modules that are part of this build over external modules on dependency resolution per default (docs).

This avoids the above conflict by always choosing the local project module on conflict.

==COMMIT_MSG==
Prefer project modules on dependency resolution per default
==COMMIT_MSG==

Possible downsides?

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Prefer project modules on dependency resolution per default

Check the box to generate changelog(s)

• Generate changelog entry

[svc-autorelease]

Released 4.63.0