AAP-14329: Add configurable virtual thread executor to gRPC service framework

[Gg-harness]

Summary

• Adds an optional Executor field to GrpcPlatformServerDefinition (defaults to null — gRPC uses its own default executor)
• When provided, the executor is passed directly to ServerBuilder.executor()
• Callers can opt into any executor type (virtual threads, custom pools, etc.) without framework changes

Motivation

EDS hits OOMKills at 500 RPS when AI SecRules are enabled because the bounded platform thread pool saturates during blocking gRPC fan-out. Virtual threads eliminate this bottleneck by decoupling concurrency from OS thread count — each blocking call yields its carrier thread instead of holding it.

This change lets EDS (and any future service) pass a virtual thread executor without the framework needing to know about VT specifics.

Changes

File	Change
GrpcPlatformServerDefinition.java	New builder field Executor executor (default null)
GrpcPlatformServiceContainer.java	Wires provided executor into ServerBuilder when non-null

Rollback

Not setting the executor field (default) preserves existing behavior — gRPC uses its own internal executor. Zero change for any service that doesn't opt in.

Test plan

• Existing tests pass (no behavioral change when executor is unset)
• Downstream EDS integration validates VT executor end-to-end
• Helm toggle (executorType: virtual → platform) provides instant rollback in production

[github-actions]

Test Results

32 tests  ±0   32 ✅ ±0   13s ⏱️ ±0s
 9 suites ±0    0 💤 ±0 
 9 files   ±0    0 ❌ ±0 

Results for commit 7f87ca5. ± Comparison against base commit b879491.

♻️ This comment has been updated with latest results.

[aaron-steinfeld]

Enum doesn't feel very extensible. Why not just take an executor, callers can opt in to whatever executor they want, virtual threads or otherwise.

[Gg-harness]

Makes sense, I'll refactor to accept an optional Executor directly. My original thinking was to centralize the reflection boilerplate (needed because of our Java 11 source constraint) + JDK < 21 fallback so every service opting into VTs doesn't reimplement the same pattern. But an open Executor field is more flexible and the duplication is minimal. Will update.

[Gg-harness]

@aaron-steinfeld updated