feat(gerrit): rework scm implementation

[felipecrs]

Important

This PR currently depends on:

• fix(gerrit): defer change creation to createPr() #39250

And is best reviewed after it is merged. The actual diff can be seen here.

Because of the alarming number of changed lines, here is the actual number when not considering the PRs above and tests:

❯ git diff --stat gerrit-fix-create-pr simplify-gerrit-scm -- . ':!*.spec.ts' ':!*spec.ts.snap'
lib/modules/platform/gerrit/index.ts |  47 +++++++++++--
lib/modules/platform/gerrit/scm.ts   | 184 +++++++++---------------------------------------
lib/modules/platform/gerrit/types.ts |   3 +-
lib/modules/platform/gerrit/utils.ts |   3 +-
lib/util/git/index.ts                |  63 ++++++++++++++++-
lib/util/git/types.ts                |  19 +++++
6 files changed, 157 insertions(+), 162 deletions(-)

Changes

This significantly refactors the Gerrit SCM to leverage the Default SCM implementation as much as possible.

On the local git repository initialization, all open changes are now fetched as remote branch references. I call these virtual branches.

The mindset here is to make the local Gerrit clone behave as similarly as possible to a GitHub/GitLab clone, so that we can reuse most of the logic from Default SCM.

The benefits are:

• Much less code to maintain in the Gerrit SCM implementation
• Dramatic reduction of the number of HTTP requests to the Gerrit server, which also leads to a dramatic performance improvement

This PR is followed up by the PR below, which completes the optimization cycle for Gerrit:

• feat(gerrit): implement pr cache #35676

Here's a comparative benchmark.

Context

Please select one of the below:

• This closes an existing Issue:
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Claude Opus 4.6 was used to implement tests and help to review the code.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: https://review.gerrithub.io/q/project:felipecrs/renovate-repro-spring-framework

[felipecrs]

This PR is in a good, functional state (tested in against a few repositories).

But it shouldn't be reviewed as it currently depends on this other one to be merged first:

• fix(gerrit): defer change creation to createPr() #39250

[felipecrs]

Old benchmarks from Oct 30, 2025

I ran some tests against a relatively big repository:

• https://review.gerrithub.io/admin/repos/felipecrs/renovate-repro-spring-framework,general

And here are some early results:

• baseline

  • ref: fix(gerrit): remove memCache to fix prNo coming as null when pr-created #38957
  • 24m37s to run
  • 931 requests

• with only SCM refactor

  • ref: this PR
  • 5m40s to run (77% faster)
  • 237 requests (75% less)

• with only PR cache

  • ref: feat(gerrit): implement pr cache #35676
  • 16m31s to run (33% faster)
  • 699 requests (25% less)

• with both SCM refactor + PR cache

  • ref: this PR + feat(gerrit): implement pr cache #35676
  • 3m26s to run (86% faster)
  • 5 requests (99.5% less)

Test method:

• All test runs had no prior cache (rm -rf /tmp/renovate) except a Redis instance shared across runs.
  • The Redis database was populated before running the baseline.
• A report was generated for the baseline run, and to ensure sanity between the runs, this report was compared to each other run's report. They all match 100%.
  • This is very deterministic in full dry-run mode, but I understand it may be vary a bit on real runs.

Here's a newer one.