[fix](logstash) Add HTTP timeouts and SO_KEEPALIVE to prevent pipeline hang (1.2.1 -> 1.2.2)

[smallhibiscus]

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #63181

Problem Summary:

logstash-output-doris 1.2.0 could hang forever on TCP half-open connections because:

1. Future.get() had no timeout
2. HttpAsyncClient had no connect/response timeouts
3. SO_KEEPALIVE was not enabled

#63181 migrated the plugin to HttpClient4 sync with NoConnectionReuseStrategy, which removes the Future.get() hang and avoids keep-alive connection reuse. However, RequestConfig still lacked connect/socket timeouts and SO_KEEPALIVE was still off. Without socketTimeout, @client.execute() can still block forever when the peer dies mid-request (same production symptom: worker threads stuck, Kafka input blocked on a full in-memory queue, pipeline throughput drops to 0).

This patch (1.2.1 -> 1.2.2):

• set connectTimeout / connectionRequestTimeout / socketTimeout on RequestConfig
• enable SO_KEEPALIVE via SocketConfig
• expose connect_timeout_ms, connection_request_timeout_ms, socket_timeout_ms as configurable options (defaults: 60s / 60s / 600s)

Release note

logstash-output-doris 1.2.2: add HTTP connect/socket timeouts and SO_KEEPALIVE to prevent worker threads hanging forever on TCP half-open connections. New optional configs: connect_timeout_ms, connection_request_timeout_ms, socket_timeout_ms.

Check List (For Author)

• Test:
  • No need to test or manual test. Explain why:
    • Other reason: HttpClient RequestConfig / SocketConfig wiring only; timeout behavior is provided by Apache HttpClient4. Existing retry path already treats execute exceptions as RETRY.
• Behavior changed:
  • Yes. HTTP requests now fail with timeout (and enter the existing retry path) instead of hanging forever on half-open connections.
• Does this need documentation?
  • No. README in this PR documents the new options.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?