Improve PMC RC verification breeze command for Airflow distribution

[shahar1]

related: #58578

Context

@amoghrajesh had introduced a great automation for verification of Airflow releases by PMC, which I found that has a potential to do more, as well as to be expanded to other types of releases.

With the help of LLM, I tried to take it to the edge (probably overengineered it 😅). At the same time I tried to consider Jarek's concern regarding "over-automation". My honest view is that the release process for all of our artifacts is very deterministic and technical (like many other problems we tackle in Airflow) - so while we need to understand what's happening as PMC, it should be automated***. At the same time, it should also be well-tested (unit tests + integration), and during execution it should reflect to ther user exactly what's happening.

Chronologically I first started to work on expanding the ability to the providers (#60802), but then I've realized that the new features could be applied here and it would make it easier to review them first on Airflow's release. After merging this PR, I will rebase my second PR for the providers and prepare it for review.

In general, I think that it would make sense to keep this feature for now experimental (mainly due to the introduced "Isolated reproducible builds" - which deviates a bit from the manual instructions), so we could adjust and stabilize it along the way in the next 2-3 releases (i.e., people who use this automation at that time - should also do the process manually).

*** - Edit (2026-01-25): considering the expected official automation using Apache Trusted Releases (ATR), it will make all checks redundant except for the reproducibility build. For that reason, this tool should be used as an experimental helper tool until the official automation is completed. After full migration, redundant checks will be deprecated and this tool will be dedicated only to reproducible checks.

What

Misc.

• Terminology nit: rename the command from validate-rc-by-pmc to verify-rc-by-pmc as it is more precise description and paired with instruction's terminology (deprecated alias kept for backwards compatibility, and will be deleted upon stabilization).
• The command is marked as experimental (--help + docs) , with clear disclaimer that builds should also be verified manually.

Core Improvements

• Existing features were relocated from AirflowReleaseValidator to parent class ReleaseValidator for enhanced reusability
• Option to download GPG keys (disabled by default)
• Option to update svn to latest revision (enabled by default, there's a flag to avoid it if unwanted)
• Add "verbose" mode to show more detailed verification reports (following Jens's feedback, enabled by default - I've retained --no-verbose for development)
• Add checks for prerequisites for fast-failure on when required tools are missing (e.g., svn, JAVA, etc.)
• Reproducible builds - run E2E using git checkout to the new branch, running the breeze commands, and then go back to the original branch. Added a check that there are no git uncommitted changes due to the temporary branch changing.
• When running all checks, all checks run according to the original order in the instructions for better parity

Note

Initially I thought of using git worktrees for reproduicble builds, but I got troubled with it. To avoid further deviation from current instructions, I fully aligned the implementation with the instructions. We could handle it after migrating to ATR.

CI/CD

• Added comprehensive set of unit tests.
• Added integration tests, testing each type of check on a pinned Airflow release (Airflow v3.1.6)
• Added a job in the GitHub workflow and selective checks configuration to run the tests

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  Claude Opus + Gemini (Core), ChatGPT (docs)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

LGTM - with the reservations I had, it might be still useful :).

But ATR fine-tuning should be our main focus :)