Limit parsec authentication PBKDF2 iteration factor to the connection time budget

plugins/auth/parsec.c accepts the PBKDF2 iteration factor from the server's ext-salt response, capped at PARSEC_ITER_FACTOR_MAX (20, raised from 3 in MDEV-35254). The factor is an exponent (effective work is 1024 << iterations, so 20 means ~1.07 billion PBKDF2-HMAC-SHA512 rounds, measured at ~7.4 min via OpenSSL on an i9-11900K; 27.8 s at factor 16, measured).

The client performs this work before authentication completes, and since it is pure computation with no intervening socket read, no timeout interrupts it. A malicious or MITM server pins a client core for minutes with a 20 iterations request.

Fix: derive the cap from the connection time budget instead of hardcoding:

budget = connect_timeout > 0 ? connect_timeout : SERVER_CONNECT_TIMEOUT_DEFAULT (10s)
maxIterationFactor = max(0, floor(log2(PBKDF2_ROUNDS_PER_MS * budget * 1000 / 1024)))

MYSQL_OPT_CONNECT_TIMEOUT is in seconds and defaults to 0 (no timeout), so the fallback is the common path rather than an edge case. PBKDF2_ROUNDS_PER_MS is a deliberately conservative throughput constant (262144 rounds / 225 ms), roughly half the measured OpenSSL rate, which keeps it safe for the nettle and BCrypt backends and for slower hardware.

connect_timeout cap work at cap
2 s (minimum) 11 0.9 s
10 s 13 3.5 s
30 s 15 13.8 s
0 (default) 13 3.5 s
The bound scales with connect_timeout by design: the client declares its own budget, and a longer declared budget permits a larger factor.

Thanks fg0x0 for reporting it.