WarnChecksumPolicy: proceed on no checksums

[ascheman]

Draft / one shape for discussion — fixes the minimal manifestation of
#1920 while leaving the larger design question open
for dev@maven.apache.org.

Change

Override AbstractChecksumPolicy.onNoMoreChecksums() in
WarnChecksumPolicy so it logs a warning and returns, instead of
inheriting the unconditional ChecksumFailureException throw.

FailChecksumPolicy is unchanged: it continues to throw via the
inherited base behavior.

WarnChecksumPolicyTest.testOnNoMoreChecksums() updated to assert the
new behavior (no exception).

Scope and framing

This is the smallest possible patch that addresses #1920's reported
behavior. It does not touch:

• the default behavior for repos without an explicit <checksumPolicy>
• file:// vs HTTP transport semantics
• the broader checksum-policy-controls space being redesigned in
  Better checksum control #1782 / Better checksum control #1784 / Checksums: lack of information #1917

Other shapes (transport-aware default in DefaultChecksumPolicyProvider,
new opt-in property like aether.checksums.noChecksumsOutcome analogous
to RRF's noInputOutcome, Maven 4 compatibility-mode flag) are
discussed separately on dev@maven.apache.org. Marking as draft so
the maintainer can decide whether this minimal shape is the right one,
or whether a broader change is preferred.

Verification

• New WarnChecksumPolicyTest.testOnNoMoreChecksums() passes locally
  (JDK 21, Maven 3.9.16, 2.0.19-SNAPSHOT).
• Full maven-resolver-impl test suite passes locally.

cc @cstamas

[cstamas]

@ascheman Sorry, was faster 😄 please take a peek at other PR and let's reconcile both PRs, as I perso like better your message!

[ascheman]

@ascheman Sorry, was faster 😄 please take a peek at other PR and let's reconcile both PRs, as I perso like better your message!

Thanks!

I intentionally started this as draft as I think there are other opportunities (larger ones, check the mail I just sent to dev Mailinglist). Nevertheless, this could be a good first approximation of a solution which we might merge until something better comes up?

[cstamas]

This is still draft, on purpose?

[ascheman]

This is still draft, on purpose?

Yes, did you see my mail on the dev list? I see the two opportunities:

• Just merge it and have a quick fix
• Consider a longer solution in the course of your anticipated redesign of resolver?

For the sake of simplicity (and speed), I would suggest, to merge it now and think about a more general solution later.

Having said that, I will now make it ready and leave it to you to merge now or discuss other solutions first.
// @hboutemy who also asked already about the more elaborated solutions proposed on the mailing list (which seem to make it unnecessary complex in this very moment).

[cstamas]

I will merge this as "least painful" thing, and later can discuss, want 2.0.19 out ASAP.

[github-actions]

@cstamas Please assign appropriate label to PR according to the type of change.