Intelligent compatibility settings for Docker tags

[rarkins]

Describe the proposed change(s).

Related discussion: https://github.com/renovatebot/renovate/discussions/26820

Here is an example of a complex tag: 24.0.7-dind-alpine3.18

In this case the most important part is Docker version (24.0.7) and type (dind), while alpine3.18 indicates the architecture.

When deciding an upgrade here, Docker version should increase, type should stay the same, while it really doesn't matter whether it's alpine 3.18, or 3.19, etc.

But in today's docker versioning, we would only process a docker version update if the tag ends in -dind-alpine3.18. Once Docker starts using 3.19 then upgrades stop as they are deemed to be incompatible. Instead the best versioning for such a tag would be loose versioning with an allowedVersions set.

The idea of this feature is for us to more dynamically decide versioning for Docker tags to avoid users needing to configure overrides manually.

Options:

• make it as part of a preset, or
• perform logic in extract phase to detect common patterns and use custom versioning/allowed instead of versioning=docker

[mschoettle]

A related discussion is in https://github.com/renovatebot/renovate/discussions/29501.

It would be great if it could handle cases where there is no type but the architecture (e.g., node:20.14.0-alpine3.19 --> node:20.14.0-alpine3.20, python:3.11.9-alpine3.19 --> python:3.11.9-alpine3.20 etc.).

There could potentially be two options (if both version and architecture increase): Separate them into two PRs or combine them in one.

[reitzig]

Also related: #24758

When we bump the "compatiblity" part of the tag in these cases, we also need to perform a similar update for all references to the matching Repology data source. Ideally, Renovate would propose those updates in a single PR