Bump error-prone to 2.40.0

[CRogers]

Before this PR

Internally, repos are being trying to take an upgrade of com.github.ben-manes.caffeine:caffeine to 3.2.2. This release of caffeine bumps the dependency of error_prone_annotations to 2.44.0.

Since we use gradle-consistent-versions and have a virtual platform for com.google.errorprone:*, this also bumps the version of error_prone_check_api used in the annotationProcessor configruation:

The current latest baseline-error-prone that is running inside the build called the ASTHelpers.findSuperMethod which got deleted in error-prone 2.39.0 (PR). This causes this error:

java.lang.NoSuchMethodError: 'java.util.Optional com.google.errorprone.util.ASTHelpers.findSuperMethod(com.sun.tools.javac.code.Symbol$MethodSymbol, com.sun.tools.javac.code.Types)'
        at com.palantir.baseline.errorprone.ThrowSpecificity.matchMethod(ThrowSpecificity.java:68)

After this PR

==COMMIT_MSG==
Upgrade error-prone to 2.40.0 and stop errors of the form when error-prone >2.39.0 is used:

java.lang.NoSuchMethodError: 'java.util.Optional com.google.errorprone.util.ASTHelpers.findSuperMethod(com.sun.tools.javac.code.Symbol$MethodSymbol, com.sun.tools.javac.code.Types)'
        at com.palantir.baseline.errorprone.ThrowSpecificity.matchMethod(ThrowSpecificity.java:68)

==COMMIT_MSG==

Upgrading allows people to upgrade dependencies that use error-prone-annotations >2.39.0.

Possible downsides?

• baseline-error-prone uses a previously published version of basline-error-prone for it's own compilation. When we upgrade error-prone in versions.props, we upgrade the error-prone used by the previous baseline-error-prone in compilation. I've worked around this using enforcedPlatform (which might even be a nice trick to stop this kind of error happening in consumer repos - but needs more though).

---

We need to verify that the new checks added are reasonable and if we want them to autofix:

$ git diff --name-only --diff-filter A v2.38.0..v2.40.0
core/src/main/java/com/google/errorprone/bugpatterns/BooleanLiteral.java
core/src/main/java/com/google/errorprone/bugpatterns/PreferInstanceofOverGetKind.java
core/src/main/java/com/google/errorprone/bugpatterns/UnnecessaryQualifier.java
core/src/main/java/com/google/errorprone/bugpatterns/formatstring/LenientFormatStringUtils.java
core/src/test/java/com/google/errorprone/bugpatterns/BooleanLiteralTest.java
core/src/test/java/com/google/errorprone/bugpatterns/PreferInstanceofOverGetKindTest.java
core/src/test/java/com/google/errorprone/bugpatterns/UnnecessaryQualifierTest.java
docs/bugpattern/ExpensiveLenientFormatString.md
docs/bugpattern/UnnecessaryQualifier.md

• BooleanLiteral (Test)
  • This one seems fine and good, they even check for Boolean.TRUE::equals that we have a few instances of internally.
• PreferInstanceofOverGetKind (Test)
  • This is also a good change which improves code by enabling destructuring to happen. Going from equal to instanceof to destructing requires compilation twice though, we'll need to keep an eye on if this breaks upgrades for error-prone sources.
• UnnecessaryQualifier (Test)
  • Fixes something with Dagger injection. Willing to let it autopatch and see what happens. Lots of usages of @Qualifer internally.

---

We also need to check that suppressible-error-prone works with 2.40.0 - I tried it on this PR and the test suites passed on this build.

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Upgrade error-prone to 2.40.0 and stop errors of the form when error-prone >2.39.0 is used:

java.lang.NoSuchMethodError: 'java.util.Optional com.google.errorprone.util.ASTHelpers.findSuperMethod(com.sun.tools.javac.code.Symbol$MethodSymbol, com.sun.tools.javac.code.Types)'
        at com.palantir.baseline.errorprone.ThrowSpecificity.matchMethod(ThrowSpecificity.java:68)

Check the box to generate changelog(s)

• Generate changelog entry

[esword]

why this flip?

[CRogers]

findSuperMethod got deleted, we have to use findSuperMethods that returns a Set instead of a single value from the set. So checking the set is non-empty should be the same as the old logic.

[esword]

ah - didn't see the change of the "s"

[autorelease3]

Released 6.42.0