Limit parsec authentication PBKDF2 iteration factor and move derivation off the event loop

lib/cmd/handshake/auth/parsec-auth.js accepts the PBKDF2 iteration factor from the server's ext-salt response, capped at 20. The factor is an exponent (effective work is 1024 << iterations, so 20 means ~1.07 billion PBKDF2-HMAC-SHA512 rounds, measured at ~7.5 min on Node 22 / i9-11900K; 28.1 s at factor 16, measured).

The derivation uses crypto.pbkdf2Sync, which blocks the event loop. A malicious or MITM server pins the entire Node process - every other connection, pending query, HTTP request and timer - for minutes with a 20 iterations request. Because connectTimeout is enforced by setTimeout, its callback cannot run while the event loop is blocked, so the configured timeout cannot interrupt the computation.

Fix 1: move the derivation off the event loop by replacing crypto.pbkdf2Sync with the async crypto.pbkdf2, which runs on the libuv threadpool.

Fix 2: cap the iteration factor at 8, and tighten further when the connection time budget is smaller:

MAX_ITERATION_FACTOR = 8
budget = connectTimeout > 0 ? connectTimeout : SERVER_CONNECT_TIMEOUT_DEFAULT (10s)
maxIterationFactor = clamp(floor(log2(PBKDF2_ROUNDS_PER_MS * budget / 1024)), 0, MAX_ITERATION_FACTOR)
PBKDF2_ROUNDS_PER_MS is a deliberately conservative throughput constant (262144 rounds / 225 ms), roughly half the measured rate.

connectTimeout	cap	work at cap

100 ms	6	27 ms

1000 ms (default)	8 (ceiling)	108 ms

10 s	8 (ceiling)	108 ms

Unlike the Java and C connectors, Node applies a hard ceiling rather than letting the bound scale with connectTimeout. The blast radius here is process-wide: unrelated connections, queries and HTTP traffic in the same process are affected

Thanks fg0x0 for reporting it.