[SPARK-56610][INFRA] Make JIRA connect timeout configurable in merge_spark_pr.py

[zhengruifeng]

What changes were proposed in this pull request?

Add a JIRA_CONNECT_TIMEOUT environment variable (default 3.05) in dev/merge_spark_pr.py, and use it as the connect-timeout component of the requests timeout tuple at both jira.client.JIRA(...) call sites.

Why are the changes needed?

The hardcoded 3.05-second connect timeout introduced in SPARK-55643 sits just past the standard TCP retransmission window — fine for a bare TCP connect on a direct connection, but too tight for a proxied TLS handshake (TCP connect to proxy + HTTPS CONNECT + TLS handshake to the target). When the script runs behind a slow HTTPS proxy, initialize_jira() fails almost immediately with:

requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='issues.apache.org', port=443): Read timed out. (read timeout=3.05)

ResilientSession's internal retry loop does not recover from this, because it only catches requests.exceptions.ConnectionError, and ReadTimeout does not inherit from it.

In practice, this makes dev/merge_spark_pr.py unusable from any environment that routes traffic through an HTTPS proxy — I cannot merge a PR from my WSL2 setup, and have to switch to another macos just for merging PRs.

Exposing the timeout as an env var lets affected users raise the limit (e.g. JIRA_CONNECT_TIMEOUT=30) without editing the script.

Does this PR introduce any user-facing change?

No. merge_spark_pr.py is a developer tool, and the default timeout value is unchanged.

How was this patch tested?

Manual test. Setting JIRA_CONNECT_TIMEOUT=30 lets dev/merge_spark_pr.py get past initialize_jira() in an environment that previously failed with ReadTimeout after ~3 s.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.7)