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

Bắt đầu với chỗ sử dụng executor được tham chiếu trong openai-java-core/src/main/kotlin/com/openai/services/async/CompletionServiceAsyncImpl.kt, sau đó lần theo OpenAIClient.builder() để tìm nơi cấu hình client được tập hợp. Xác định executor đã cấu hình cần được truyền đến dịch vụ bất đồng bộ như thế nào, và xác minh rằng các lệnh gọi HTTP bất đồng bộ sử dụng nó thay vì 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.