[9.3.0] Keep an unrelated fetch from using up the memory pressure drop budget in a test (https://github.com/bazelbuild/bazel/pull/30757)

[bazel-io]

Description

testMemoryPressureRestartDuringCachedFetch relies on a compute state drop landing while the cached fetch of my_repo is in flight, but the budget of --skyframe_high_water_mark_minor_gc_drops_per_invocation is shared by every fetch in the invocation. On Windows, test_base registers a Python toolchain from rules_python, so every attempt starts by fetching that repo, whose contents are large enough to use up all 8 drops within the first few seconds. No full GC happens afterwards, so the fetch under test is never interrupted.

rules_python is now fetched before the poison build, without a remote cache so that it ends up on disk rather than being injected into the memory of the server that runs the fetch: the poison build uses a different server (it sets --host_jvm_args=-Xmx512m) and would otherwise have to inject it again.

Motivation

The test is flaky on Windows:

AssertionError: the cached fetch of my_repo was never both interrupted by a memory-pressure compute state drop and served from the cache

I instrumented it on Windows CI to log every state drop and every fetch restart to the server log. In a run of 30 attempts, only 2 saw a restart of my_repo; every drop in the other 28 was spent on a restart of @@rules_python+, all 8 of them within the first ~5 seconds of the build. With this change, all 25 attempts of a run of the same shape were interrupted while still being served from the cache.

The same runs also uncovered a crash that this test can hit on any platform, fixed in #30756.

Build API Changes

No

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: None

Closes #30757.

PiperOrigin-RevId: 966480487
Change-Id: I57dd23bb2e2dd4e73b352deaf476214cff4f66a7

Commit d59116e