Allow custom executor/thread pool for async HTTP calls in CompletionServiceAsyncImpl

Comienza con el uso del executor referenciado en openai-java-core/src/main/kotlin/com/openai/services/async/CompletionServiceAsyncImpl.kt y, después, sigue OpenAIClient.builder() para encontrar dónde se ensambla la configuración del cliente. Determina cómo debe llegar el executor configurado al servicio asíncrono y verifica que las llamadas HTTP asíncronas lo utilicen en lugar de ForkJoinPool.commonPool().

Description

CompletionServiceAsyncImpl currently uses the JVM ForkJoinPool.commonPool() to invoke async HTTP calls:

https://github.com/openai/openai-java/blob/main/openai-java-core/src/main/kotlin/com/openai/services/async/CompletionServiceAsyncImpl.kt#L143

In enterprise environments, relying on the global common pool can break tracing, observability, and context propagation flows. Many applications use custom executors/thread pools to preserve tracing context, MDC/logging context, OpenTelemetry context, or other request-scoped metadata across async boundaries.

Because the common pool is not customizable, users cannot currently integrate the OpenAI Java client cleanly with their existing execution and observability infrastructure.

Problem

There is currently no supported way to override the thread pool used by CompletionServiceAsyncImpl.

The only workaround is to copy the generated/service implementation class and modify the executor usage manually, which is fragile and difficult to maintain across library upgrades.

Proposed Solution

Provide an option to configure the executor/thread pool when building the client.

For example:

val client = OpenAIClient.builder()
.apiKey(apiKey)
.executor(customExecutor)
.build()

or, if scoped specifically to async execution:

val client = OpenAIClient.builder()
.apiKey(apiKey)
.asyncExecutor(customExecutor)
.build()

The async service implementation could then use the configured executor instead of ForkJoinPool.commonPool().

Expected Behavior

Users should be able to supply a custom executor so async HTTP calls run on infrastructure-controlled threads, allowing tracing, observability, and context propagation to work correctly.

Current Workaround

The current workaround is to copy CompletionServiceAsyncImpl and modify the implementation to use a custom executor, but this is not ideal because it forks library internals and creates maintenance risk.

Additional Context

This is especially important in enterprise scenarios where applications require strict control over execution context, thread naming, tracing propagation, and monitoring behavior.