ci: wire the EL7 functional job into #777's quarantine machinery - #810

functional-tests.sh is about to wrap its gradlew invocation in
run_tests_with_retry.sh, which shells out to quarantine.py and
flake_report.py.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

functional:x64-el7-jdk* previously just ran gradlew directly and let
its raw exit code decide the job -- ddprof-test/quarantine.txt had no
effect on it at all, unlike the GH Actions matrix (#777). Wraps the
gradlew invocation in run_tests_with_retry.sh with cell
"el7-<jdk>-<config>-amd64".

MAX_ATTEMPTS defaults to 1 (no retry) here specifically: the default
of 2 means a full second suite run, and this runner has already
OOMKilled the container outright once at the current heap/concurrency
(PR #805). Losing the flaky-vs-broken distinction is an acceptable
trade for not doubling memory pressure on a runner already this
tight; revisit once there's more headroom.

Extends .functional_job's artifact paths with flake-evidence/,
ci-outcome/ and build/logs/attempt.log so a quarantine decision on
this job has evidence to show for it.

Verified end-to-end inside the real Oracle Linux 7 image with a stub
gradlew: a quarantined failure on its own cell now exits 0 through
the full functional-tests.sh-shaped invocation.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

PROF-16014. Root-caused in PR #805: NativeSocketSampler's hooks
install and fire correctly (confirmed via a debug-config diagnostic
build), but the rate limiter rejects nearly every sample because
NativeSocketTestBase.doTcpTransfer()'s assumption that the send
buffer fills and blocks after ~32 iterations does not hold on this
runner's network stack.

Scoped to el7-8-release-amd64, the only cell this has actually been
observed on -- not el7-*-release-amd64, so the nightly el7-17/-21
cells still gate for real if this doesn't reproduce there the same
way.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

The example line was written to be deleted once the first real entry
landed, but it's worth keeping as a permanent format reference -- the
NativeSocket entries are tied to a bug that will get fixed and
removed, and the file shouldn't go back to having no example once
that happens.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

Inserting it in the module-level constants block left it wedged
between two densely-packed constant groups with no blank-line
separation, breaking the file's own two-blank-lines-around-defs
convention. Moves it next to is_expired(), its first caller, matching
how the file already places its other small helpers near their use.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

Flagged in review, and confirmed against both the test source and
quarantine.txt's own documented format: every affected class's single
test method is @RetryingTest, which -- like @ParameterizedTest and
@testtemplate -- reports in JUnit XML as "Class.[1]", "[2]", ... with
no method name at all. The exact-method entries could never match
anything; only the already-class-wide NativeSocketStackTraceTest.*
entry ever worked. Converts the other 8 to <class>.*.

Also drops the NativeSocketUdpExcludedTest entry entirely rather than
widening it: that test asserts *zero* events, which the bug's own
symptom (near-zero events everywhere) would make pass, not fail. Its
earlier observed failure has an unconfirmed, likely different cause,
and quarantining it on this evidence risks hiding an unrelated
regression later.

Verified: find_entry() now matches the real
"NativeSocketEnabledTest.[1]"-shaped id against the class-wide entry,
and confirms the UDP test is not quarantined. All 59
test_quarantine.sh assertions and quarantine.py validate still pass.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

Built and pushed successfully in pipeline 139300629 (the job's
overall failure was two unrelated images, arm64-musl and
benchmarks-amd64). Confirmed python3 3.6.8 installed in the build log.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

The x64-el7 functional job was getting OOMKilled (exit 137) at the
container level during pod cleanup, after the test suite had already
finished and uploaded its artifacts. The JVM under test already has
its own -Xmx1536m cap; the pod itself needed more headroom to run
Gradle's daemon/workers, the gtest builds, and the JVM together.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

The Kotlin compile daemon outlives the build-logic compile and stays
resident for the rest of the build, including the whole test run, next to
the Gradle process and the test JVMs. Measured on a --no-daemon build:
~580MB Gradle + ~660MB Kotlin daemon with the default strategy, versus
~920MB Gradle and no daemon in-process. The out-of-process strategy was
removed in Kotlin 2.4.0.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

…mon"

This reverts commit 7864e74.

The Kotlin compile daemon (~660MB RSS) stays resident through the whole
test run in this 6GB pod. Setting in-process globally via
build-logic/gradle.properties broke the CodeQL Java job: its Kotlin
extractor runs inside the compiler, and in-process that exhausted
Gradle's default 512m heap. Scope the setting to this job instead.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

This reverts commit a794f69.

gradle.properties.template documents skip-native=true, but isNativeSkipped()
only treated an empty value as the global skip and read anything else as a
list of project names. "true" matched no project, so native compilation ran
anyway. Treat "true" like a bare -Pskip-native, and "false" as skipping
nothing.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>