Trim fd_set memory, fix timeout math, stop busy-spinning in verify(jwt)

[djw8605]

Three related I/O-loop cleanups:

1. ~384 KB of fd_sets per in-flight request

SimpleCurlGet declared its select() sets as fd_set m_read_fd_set[FD_SETSIZE] — an array of 1024 fd_sets (×3 members) where a single fd_set (which already holds FD_SETSIZE descriptors) was intended. Roughly 384 KB of wasted memory per SimpleCurlGet, i.e., per in-flight verification. It only worked because the arrays decayed to a pointer to their first element.

2. Timeout math in AsyncStatus::get_timeout_val()

Computed 100 * (seconds remaining) where every other site converts seconds→ms with 1000 (compare SimpleCurlGet::perform). C-API event loops using scitoken_status_get_timeout_val therefore polled 10× more often than intended. It also produced a negative timeval once the deadline passed — invalid for select() (EINVAL). Now 1000 * with a clamp at zero.

3. Busy-spin in verify(jwt)

The verify(const jwt::decoded_jwt&) overload — the path scitoken_deserialize uses — looped verify_async_continue() with no select() at all, pinning a CPU core for the full duration of any JWKS fetch over the network. It now waits on the transfer's descriptors (capped at 1 s) and continues unconditionally afterward, as libcurl requires after timeouts.

Testing

• ctest unit, env_config, and monitoring suites pass (deserialize tests exercise the reworked loop).

🤖 Generated with Claude Code