Fix unitTest task not running the test source set

[loggk]

Description

./gradlew unitTest runs 1 test class instead of 170. The tests under src/test/java are never executed locally or in CI. Nothing in CI runs the plain test task either (test-unit.yml runs unitTest, build.yml runs build -x test), so those ~200 test files are executed by no workflow at all.

unitTest resolves its test classes from the java21 source set, which declares src/test/java11 and src/test/java21 but not src/test/java. So the main test source set is compiled but never run.

This is original wiring rather than a regression: unitTest has never had testClassesDirs set, having been a bare task<Test> with only a filter since 3b34f60 (Aug 2021), so it ran zero tests. #968 later moved the JDK source set wiring from tasks.test onto unitTest/integrationTest, which incidentally gave it the java11/java21 classes. That is why it runs exactly one class today rather than none.

Changes

Add the test source set's output to unitTest's testClassesDirs, so the task resolves the tests in src/test/java alongside the JDK-specific source sets.

Also fix two timing-flaky tests that re-enabling the suite surfaced. BulkIngesterTest.periodicFlushTest and failingListener slept 100 ms between operations against a 50 ms flush interval and asserted exactly one request per operation. Under load two operations share a flush window and get coalesced. They now wait on requestCount() reaching the expected value rather than on wall-clock time, which is both deterministic and faster.

Verified with ./gradlew :java-client:unitTest: this takes the run from 1 test class to 170 (426 tests, 0 failures on JDK 21 and JDK 25). An unconditionally failing test added under src/test/java, which still reports BUILD SUCCESSFUL on main, correctly fails the build with this change. RequestOptionsTest from src/test/java11 still runs, no integTest classes leak into unitTest, and spotlessJavaCheck passes.

Notes

One thing turned up while diagnosing this that is not addressed here, recorded in #2075.

Java 8. This change lives inside the runtimeJavaVersion >= 21 branch, so the JDK 8 path is untouched: unitTest still has no classpath there and continues to compile and run nothing, which is why test-java8 stays green. Wiring that job up reveals that java-client no longer compiles under Java 8 at all, since tools.jackson.core ships Java 17 class files (class file has wrong version 61.0, should be 52.0), failing in :java-client:compileJava before tests are even considered. That looks like it dates to #1810. Happy to open a separate issue if that is useful.

Issues Resolved

Related to #2075

Check List

• Commits are signed per the DCO using --signoff
• Changelog updated

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[opensearch-ci-bot]

The backport to 3.x failed. Please backport manually. See failed workflow run: https://github.com/opensearch-project/opensearch-java/actions/runs/30678260982

[reta]

The backport to 3.x failed. Please backport manually. See failed workflow run: https://github.com/opensearch-project/opensearch-java/actions/runs/30678260982

@loggk would you mind please to backport to 3.x branch as well? thank you