GeezerVison

Follows the deprecation in #3956.

• Bump the minimum CodeQL version to 2.20.7 and add a changelog note.
• Bump the minor version number.
• Update the CodeQL versions tested by PR checks: drop 2.19.4, test 2.20.7 rather than 2.20.3 in the debug artifact checks, and add 2.25.6, which ships with GHES 3.22.
• Remove code that is only needed for CodeQL versions older than 2.20.7:
  • Unsetting empty CODEQL_PROXY_* environment variables in analyze.
  • The Kotlin version limit override for CodeQL 2.20.3.
  • The CodeQL version check before uploading debug artifacts.
  • The Rust minimum version check (2.19.3) and the minimum version for C++ dependency installation (2.15.0). These were already redundant with the previous minimum version.

All the tools features are still needed, since CodeQL 2.20.7 doesn't report any of them as supported. The README compatibility table and the next deprecation are handled in #4188.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.
• Third-party analyses - The changes affect the upload-sarif action.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

• Special considerations - The required checks need updating with pr-checks/sync-checks.ts before merging, since this changes the CodeQL versions in the PR check matrix.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.