perf(flagd): run all 3 e2e resolver modes concurrently via @TestFactory

[aepfli]

Summary

Stacked on top of #1752. Replaces three sequential @Suite runner classes with a single RunE2ETests class using Jupiter @TestFactory methods, cutting wall-clock time from ~3:20 to ~2:00.

Changes

1. RunE2ETests — three concurrent @TestFactory methods

Each factory (rpc(), inProcess(), file()) launches a full Cucumber engine for its resolver mode. With @Execution(CONCURRENT) and junit.jupiter.execution.parallel.enabled=true, all three engines run simultaneously:

Before: RPC (sequential) → InProcess → File  ≈ 3:20
After:  RPC ──┐
              ├── all run in parallel ──→ ≈ 2:00
         File ┘

Each factory returns a Stream<DynamicNode> mirroring the Cucumber TestPlan (engine → feature → scenario), so IDEs show the full expandable tree with accurate pass/fail/skip per scenario — individual scenarios can be re-run from IntelliJ.

2. CucumberResultListener — full TestExecutionListener

Captures every lifecycle event (started, finished, skipped, dynamic) from the Cucumber engine and maps them to DynamicTest results. The listener tracks both started and finished state to correctly report scenarios that started but did not complete.

3. ContainerPool — JVM shutdown hook + restart semaphore

• Lazy ensureInitialized() via AtomicBoolean — pool starts once on first acquire(), shared across all three concurrent engines
• JVM shutdown hook replaces the previous ref-counted initialize()/shutdown() — no lifecycle calls needed from test classes
• Semaphore(1) serialises disruptive container operations (stop/restart) across parallel engines to prevent cascading init timeouts

4. Per-resolver glue packages

RpcSetup, InProcessSetup, FileSetup — each a simple @Before hook that sets state.resolverType, allowing all three engines to share the same step definitions with isolated per-scenario state.

5. Deleted RunRpcTest, RunInProcessTest, RunFileTest

No longer needed — RunE2ETests replaces all three.

6. Envoy cluster improvements (test-harness submodule)

Added connect_timeout: 0.25s and active TCP health checks (interval: 1s) to both flagd clusters in envoy config. Envoy now detects and recovers from upstream flagd restarts within one health-check cycle.

Known limitations

• @targetURI @in-process scenarios (7) are excluded from the parallel run. Root cause: retryBackoffMaxMs controls both the initial-connection throttle in SyncStreamQueueSource (when getMetadata() fails because envoy's upstream isn't ready yet) and the post-disconnect reconnect backoff. These cannot be tuned independently — reducing the backoff for fast initial connection breaks the reconnect event timing tests. Tracked in flagd#1584 — once getMetadata() is removed, these can be re-enabled by removing "targetURI" from the inProcess() excludeTags.
• file()[4][1-3] — FILE resolver lacks flag-set metadata support (SDK limitation, pre-existing)
• inProcess()[3][2], [6][1-3], [8][2] — contextEnrichment failures (pre-existing, also fail on base branch)

Run from repo root

./mvnw -pl providers/flagd -Pe2e test

[gemini-code-assist]

Code Review

This pull request refactors the flagd E2E test suite to support concurrent execution of RPC, in-process, and file resolver modes using JUnit 5 @testfactory. It introduces a lazy-initialized ContainerPool with a JVM shutdown hook, a semaphore for managing container restarts, and improved synchronization for gRPC and file availability. Feedback identifies a thread-safety issue in CucumberResultListener and suggests optimizing ContainerPool initialization to reduce lock contention.