Lazy Maven version validation

[rarkins]

Describe the proposed change(s).

Today we validate each maven datasource version/result just in case:

renovate/lib/modules/datasource/maven/index.ts

Lines 216 to 225 in 745978f

	async addReleasesUsingHeadRequests(
	inputReleaseMap: ReleaseMap,
	dependency: MavenDependency,
	repoUrl: string,
	): Promise<ReleaseMap> {
	const releaseMap = { ...inputReleaseMap };
	if (process.env.RENOVATE_EXPERIMENTAL_NO_MAVEN_POM_CHECK) {
	return releaseMap;
	}

The downside of this is that we need to do N checks for N versions of a package, which can introduce a lot of load for registries both public and private.

We should refactor our logic instead like this:

• No longer proactively/eagerly checking every release
• Add a new optional method in datasources called validateRelease() for Maven. It should cache very aggressively
• Instead, once we select a release for upgrading to, we then call validateRelease() to make sure it's valid, and fall back to lower releases in the "bucket" if it fails the check, similar to how we drop versions for reasons like minimum release age

This would be a better alternative to the breaking change proposed in #30415

[zharinov]

I almost came up with the working example, and suddenly things got weird: in Maven case, our checks are HEAD requests of the corresponding .pom files, but we also use Last-Modified header as our releaseTimestamp. If we stop those checks, we're losing releaseTimestamp fields, and therefore minimumReleaseAge checks are skipped.

If we still want to go this way, the extended datasource API will look like this:

interceptRelease(config: Release): Promise<Release | null>;

This could reject the release by returning null, or it could enrich its data by attaching releaseTimestamp and whatnot. Once non-null value is returned, further confidence level and minimumReleaseAge checks are performed.

As far as I can remember, we have one or two datasources lacking releaseTimestamp support, because it takes N+1 HTTP requests to obtain them. Hopefully, this approach could solve it.

[rarkins]

Yes, please go ahead with that approach