Replace Tito releases with rhpkg and automatic Koji tagging

[Odilhao]

Summary

Replace Tito release integration with rhpkg dist-git builds and obal-managed Koji/Brew tag reconciliation. This implements the missing Brew/dist-git workflow discussed in #380 and #294, and addresses the existing-build tagging problem from #424.

• Remove Tito release/build modules, wrappers, extensions, setup installation, and release defaults.
• Use rhpkg for dist-git releases. Configure branches, build targets, RPM macros, and destination tags separately with rhpkg_targets.
• Default rhpkg release, scratch, check, and tag-verification operations to brew. Preserve explicit command overrides and direct Koji defaults.
• Preserve direct Koji SRPM submission through build_package_releaser: koji or the existing build_package_use_koji_build: true setting.
• Preserve COPR's native SRPM and copr-cli workflow. Setup reads package inventory settings and installs neither Tito nor rhpkg for COPR inventories.
• Install Git and git-annex as shared dependencies for source preparation across all backends.
• Keep package_whitelist_check and support both explicit tag lists and legacy releaser configuration for registration checks. Share its registration query with the rhpkg flow and check missing destination tags before promoting existing builds; missing/blocked packages and query failures stop tagging. These checks default on for rhpkg releases and do not gate scratch builds.
• Reuse complete NVRs and apply only missing tags. For missing builds, stage spec sources and patches, upload lookaside sources, push dist-git, and submit through rhpkg.
• Persist pending task receipts for retries and asynchronous release and scratch builds; verify completed builds and tag membership. Scratch reruns reuse pending tasks after validating the spec, sources, NVR, and target, and retain the receipt on validation failure. Query and push failures prevent submission, and independent targets are attempted before waiting.
• Submit scratch SRPMs directly through the configured Koji/Brew client. Scratch does not invoke rhpkg, push dist-git, or apply release tags. Preserve destination checks through obal check and inventory tag verification.
• Preserve structured tag configuration in the legacy diff path and use the configured Koji/Brew executable consistently.
• Allow native SRPM builds to consume locally supplied nightly sources whose spec entries are URLs.

Compatibility and migration

Tito is no longer an available releaser. Existing Tito inventories must configure rhpkg_targets; legacy rel-eng/releasers.conf settings are not translated automatically. Missing target configuration and an explicit Tito selection fail with a diagnostic.

COPR inventories retain build_package_build_system: copr. Existing direct Koji inventories can retain build_package_use_koji_build: true.

Custom Tito source/test builders, including setup_sources_git, are unsupported. Asynchronous release and scratch invocations save receipts; rerun the same action with waiting enabled to finish. Once a scratch task has been completed through obal, a subsequent scratch invocation can submit a new build. No live Brew release has been submitted.

Prebuilt gems and tarballs referenced by the spec remain supported through local files or git-annex. The removed setup_sources_git task cloned a project source repository and handed source_dir to a Tito builder; it was separate from rhpkg's dist-git checkout. Pipelines that generate artifacts before updating the packaging repository use the existing spec/annex source path.

Regression coverage

Add 48 Brew regression cases using public Foreman package versions to simulate promotion from rpm/develop to rpm/5.0. Tests use real Git and RPM tools with local dist-git repositories and stateful Brew/rhpkg clients. Coverage includes existing-build promotion, version/release and macro changes, multiple destinations, task recovery, partial tag failures, scratch isolation and resumption, changed-input rejection, default command selection and overrides, downloads, registration checks, rejected legacy configuration, and preservation of dist-git service files.

Replace obsolete Tito expectations and retain the existing COPR tests. Five setup tests verify dependency selection for COPR, direct Koji, and rhpkg inventories, plus setup without any package inventory, without installing packages on the test host.

Validation

• GitHub CI: Python 3.9–3.13, lint, and container jobs all passed on f580f84.
• Full Python suite and flakes: 232 checks passed as an unprivileged user on Python 3.12 / CentOS Stream 10, including native Koji, COPR, nightly, and annex source handling.
• Pylint: 10.00/10.
• Changed Ansible files and their includes passed ansible-lint, including the restored whitelist task and annex/setup changes; custom-module import warnings were emitted.
• Distribution manifest, setup.py check -m -s, and git diff --check: passed.

The annex regression drops local content, fetches it from a non-web annex remote, and verifies the actual source bytes inside the submitted scratch SRPM while preserving the annex link. Brew command semantics were checked in the existing Satellite tooling container; no live build or tag was submitted.

Documentation files are excluded from this change.

[zjhuntin]

Found some issues, here ya go:

[zjhuntin]

P2 — This passes build_package_koji_command, whose role default is still koji (obal/data/roles/build_package/defaults/main.yaml:3). That overrides rhpkg_release.py's koji_executable default of brew, so an rhpkg configuration that does not explicitly override the command will send build queries and tag operations to koji rather than Brew. Could this select brew by default in rhpkg mode, or validate/document the required override?

[zjhuntin]

P2 — This bypasses receipt resumption whenever scratch mode is enabled. If a scratch release is run with build_package_wait=false and invoked again to finish it, the saved task is not reused: a new scratch task is submitted and the receipt is overwritten. Could scratch mode resume its recorded task IDs too (while validating the requested inputs), and add a rerun regression test?