--write-locks no longer implicitly runs checkClassUniqueness task

[iamdanfox]

Before this PR

I've become frustrated with how the local experience of writing ./gradlew --write-locks has become very slow. This is often because checkClassUniqueness is a pretty meaty task, which ends up analyzing all jars on the classpath.

After this PR

==COMMIT_MSG==
Running ./gradlew --write-locks should be faster now, as it doesn't update your baseline-class-uniqueness.lock file implicitly anymore. To update this, you need to run ./gradlew checkClassUniqueness --write-locks.
==COMMIT_MSG==

Possible downsides?

A big downside here is: if we just merge this PR, then a bunch of excavators will probably start opening PRs with out of date baseline-class-uniqueness.lock files, leading to frustrated devs.

[changelog-app]

Generate changelog in changelog/@unreleased

Type

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

Description

Running ./gradlew --write-locks should be faster now, as it doesn't update your baseline-class-uniqueness.lock file implicitly anymore. To update this, you need to run ./gradlew checkClassUniqueness --write-locks.

Check the box to generate changelog(s)

• Generate changelog entry

[carterkozak]

Looks like our error message already suggests checkClassUniqueness --write-locks 👍

[svc-autorelease]

Released 3.24.0