建议为 TimeoutServiceClient 支持外部注入线程池（且 shutdown 不接管外部池）

背景与问题

在 0.6.153 中，构造 Client 时若 ClientConfiguration#setRequestTimeoutEnabled(true)，
Client.buildServiceClient 会创建 TimeoutServiceClient（src/main/java/com/aliyun/openservices/log/Client.java:216-221）。

该实现内部持有一个独立 ThreadPoolExecutor：

• 默认 core=procs5、max=procs10、queue=procs*100（TimeoutServiceClient.java:47-51），即每个 Client 实例都拥有自己的平台线程池。
• shutdown() 无条件对该 executor 调用 shutdown() / awaitTermination() / shutdownNow()
  （TimeoutServiceClient.java:101-115）。

影响场景

我们直接用 Client（非 producer）异步并发写 logstore：

• Java 8 时代：并行度 ~50，每个 Client 自带线程池可控，无问题。
• 升级 Java 21 后：希望用虚拟线程把发送并行度抬高一个数量级，但
  • 每个 Client 一个平台线程池 → 平台线程数随 Client 数量线性放大，系统资源被快速耗光，单组投递时延反而升高；
  • 关掉 requestTimeoutEnabled（走 DefaultServiceClient）虽更轻量，但请求超时只能依赖 connectionTimeout / socketTimeout，对慢响应控制不够精确。

现状

仓库已经有"半个解"：

• TimeoutServiceClient(ClientConfiguration, ThreadPoolExecutor) 构造（TimeoutServiceClient.java:70-73）实际接受外部 executor；
• Client(String, CredentialsProvider, ServiceClient, String) 构造（Client.java:237）允许传入预构造的 ServiceClient。
• 但 TimeoutServiceClient#shutdown() 仍会无条件停掉这个 executor，外部传入的虚拟线程池会被一起关掉——业务侧难以共享/复用线程池。

建议

1. 给 TimeoutServiceClient 增加一个标记位（如 ownsExecutor），在使用外部注入的 executor 时不在 shutdown() 里调用 executor.shutdown*()，由调用方自行管理生命周期。
2. 在 Client 公共 API 上提供一条更直接的入口，比如：

   public Client(String endpoint, CredentialsProvider credentialsProvider,
                 ClientConfiguration config, ExecutorService externalExecutor, String sourceIp);
   

   或允许在 ClientConfiguration 上设置一个 ExecutorService 字段，buildServiceClient 检测后走 TimeoutServiceClient(config, externalExecutor) 分支。
3. Javadoc 中明确"外部 executor 由调用方负责 shutdown"的语义。

收益

• Java 21+ 用户可注入虚拟线程池，单 Client 资源占用大幅下降，
  并行发送 + 资源利用率都能上一个台阶；
• 不破坏现有 BC：未注入 executor 时行为不变。

环境

• aliyun-log-java-sdk: 0.6.153
• JDK: 21 (项目原为 8)
• 使用方式：直接调 Client，未走 aliyun-log-java-producer

Start with src/main/java/com/aliyun/openservices/log/TimeoutServiceClient.java, especially the constructors and shutdown() at lines 70-73 and 101-115, then inspect Client.java at lines 216-221 and 237. Define how injected and internally created executors differ, expose the chosen Client entry point, and document ownership. Done means external executors remain usable after shutdown while existing behavior is unchanged.