feat(docker): determine `releaseTimestamp` for a given Docker digest via Registry APIs

[jamietanna]

Describe the proposed change(s).

As noted in #38212, we are not currently determining the Docker digest's releaseTimestamp date, which leads to issues when using minimumReleaseAge.

We should use the Registry APIs via:

/v2/.../manifests/...
/v2/.../blobs/...

[jamietanna]

Might be a duplicate of #24053, but this would be looking at using the registry APIs, not a Docker Hub specific means of surfacing this data

[jamietanna]

(still deciding if this is a bug or a feature - likely a feature)

[jamietanna]

Digging into this more, we do already support this, if the tag_pushed_at is returned (purely for Docker Hub #38989)

We should change this - likely as a breaking change - and then improve our support at some later point.

[wwuck]

@jamietanna Would this allow support for minimumReleaseAge when using a docker pull-through cache?

I am currently using the official docker distribution release for a pull-through cache. Running into the problem that I either set this cache address in registryAliases for avoiding docker hub rate limiting, or I remove from registryAliases to get the minimumReleaseAge support for docker datasource and get hit with the rate limits from docker hub.

Can be tested using this docker-compose.yml:

---
name: docker-registry-mirror

services:
  registry:
    restart: always
    image: registry:3
    ports:
      - target: 5000
        host_ip: 127.0.0.1
        published: 5000
        protocol: tcp
        mode: host
    environment:
      OTEL_TRACES_EXPORTER: none
      OTEL_METRICS_EXPORTER: none
      OTEL_LOGS_EXPORTER: none
      REGISTRY_HTTP_H2C_ENABLED: 'true'
      REGISTRY_LOG_LEVEL: info
      REGISTRY_PROXY_REMOTEURL: https://registry-1.docker.io
      REGISTRY_STORAGE_DELETE_ENABLED: 'true'
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
    healthcheck:
      test: netstat -ltn | grep -c ":5000"
      timeout: 5s
    pull_policy: always

I have it sitting behind haproxy for TLS termination, but that shouldn't affect the result I hope.