Add container-registry upstream support to bump-upstream action

[Pol-Lanski]

Problem statement

dappnodesdk github-action bump-upstream currently assumes that an upstream package version is discovered from GitHub releases/tags. That works for packages whose source of truth is a GitHub repo, but it does not work for packages whose real upstream is a container image registry.

A concrete example is dappnode/DAppNodePackage-Snowflake:

• the package builds from containers.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake:${UPSTREAM_VERSION}
• the real upstream project lives on GitLab, not GitHub
• the current scheduled bump-upstream workflow therefore cannot correctly detect new upstream versions using the existing GitHub-only logic

As a result, packages like Snowflake cannot use the standard SDK automation unless they add custom workflows outside the SDK.

Goal

Extend the SDK so github-action bump-upstream can detect upstream versions from a container registry in addition to GitHub releases.

Proposed scope

Add a new upstream source type for container registries.

Manifest support

Introduce manifest fields to describe a container-registry upstream, for example:

{
  "upstreamVersion": "1.2.3",
  "upstreamType": "container-registry",
  "upstreamImage": "containers.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake",
  "upstreamArg": "UPSTREAM_VERSION"
}

find the example here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/container_registry/11

Backward compatibility:

• existing GitHub-based packages should continue working unchanged
• if upstreamType is omitted, preserve current GitHub behavior

Expected behavior

When upstreamType is container-registry, the bump-upstream action should:

1. Read the configured image reference from the manifest
2. Query the registry for available tags
3. Select the newest valid stable release tag
4. Ignore tags like latest, pre-releases, and non-version tags unless explicitly supported
5. Compare the discovered upstream version with the manifest/docker build input currently in use
6. If a newer version exists:
   • update the configured build argument in the package
   • open the same kind of bump PR that existing GitHub upstream support creates

Notes for Snowflake

This should support the Snowflake package use case where the Dockerfile contains:

ARG UPSTREAM_VERSION=latest
FROM containers.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake:${UPSTREAM_VERSION}

and the upstream source of truth is the published container tags, not GitHub releases.

Acceptance criteria

• Existing GitHub-upstream packages continue to work with no manifest changes
• A package can declare a container-registry upstream in its manifest
• github-action bump-upstream can discover newer version tags from that registry
• The action ignores unsupported/non-stable tags in a predictable way
• The action opens the expected bump PR when a newer stable upstream version is available
• Documentation is updated with an example manifest and workflow usage

Nice-to-have

• Support registries beyond GitLab if feasible
• Add a pluggable upstream-provider abstraction so GitHub releases and container registries share a common interface
• Add tests covering semver tags, latest, invalid tags, and pre-release filtering

If you want, I can also turn this into:

• a GitHub issue body, or
• a problem statement ready for a coding-agent PR in dappnode/DAppNodeSDK.