fix(ext/node): dns resolveAny with real ANY query, retry/maxTimeout support

[bartlomieju]

Depends on #33571.

Summary

• Replaces queryAny's 11 separate DNS queries with a single ANY query by adding RecordType::ANY support to op_dns_resolve. For ANY queries, each record's actual type is used for formatting, and a record_type field is included to let the JS layer distinguish untagged string variants (A vs NS vs PTR vs CNAME).
• Implements retry logic in the DNS resolver: timeout doubles on each retry attempt, capped by the new maxTimeout option.
• Adds maxTimeout option validation to the Resolver constructor (valid range: 0 to 2^31-1).
• Enables 3 more Node.js compat tests:
  • parallel/test-dns-resolveany.js
  • parallel/test-dns-resolveany-bad-ancount.js
  • parallel/test-dns-resolver-max-timeout.js

Test plan

• ./x test-compat test-dns-resolveany — both pass (resolveany + bad-ancount)
• ./x test-compat test-dns-resolver-max-timeout passes
• All 11 DNS compat tests from this PR + fix(ext/node): implement dns.reverse() and fix dns.lookup() family parameter #33571 pass

[fibibot]

Substance is mostly right — single ANY query replacing the 11-parallel-query workaround is a real improvement, and the per-record recordType field gives JS the type info it needs to dispatch on string-typed variants (A vs NS vs PTR vs CNAME). validateMaxTimeout correctly clamps to [0, 2^31-1] and the retry loop's timeout * 2^attempt capped by maxTimeout mirrors c-ares.

A few things to clean up before this lands:

1. Dependency stale: body says "Depends on #33571" but #33571 was closed in favor of #33579 (already merged). Rebasing onto current main will pull in #33579's dns.reverse() + dns.lookup({ family }) work, which already touches cares_wrap.ts. Conflicts likely.

2. #pendingQueries field overlap with #33580: that PR also adds #pendingQueries: Set<QueryReqWrap> to ChannelWrap. One of the two will need to rebase.

3. Same Promise.race + setTimeout issues I flagged on #33580:

   • Timer leak: when DNS resolves first, the setTimeout fires for nothing later but keeps the event loop alive currentTimeout ms.
   • Orphan op: ETIMEOUT just rejects the race — the underlying op_dns_resolve keeps running. With tries=4 and timeout=1000, a slow resolver can spawn 4 concurrent op invocations all racing to complete while JS thinks they timed out.
   • #33580's latest commit switches to core.createCancelHandle() + core.tryClose(cancelRid) to actually abort the op — that approach should be lifted into here too once #33580 merges.

4. Field-name serialization (verify locally — flagging the ambiguity): the new pub record_type: Option<String> field in DnsRecordWithTtl is read in JS as entry?.recordType (camelCase). The existing data/ttl fields are accessed as-is because they're already lowercase. If #[derive(ToV8)] doesn't auto-camelCase fields, JS would need to read entry?.record_type (snake_case) or the dispatch switch silently falls through and records ends up empty. The PR body says "all 11 tests pass locally" so either ToV8 does camelCase, or the test isn't exercising dispatch — worth a quick console.log(entry) to confirm.

CI not yet complete (56/n passing, no failures yet). I'll re-confirm once it lands and the dependencies above are sorted out.

[bartlomieju]

This PR depends on #33580 (cancel handle support for DNS ops) being merged first. The tests registered here (test-dns-resolver-max-timeout.js, test-dns-resolveany-bad-ancount.js, test-dns-channel-cancel.js) time out on CI because cancel() only fires JS callbacks without aborting the underlying op_dns_resolve -- the cancel handle implementation in #33580 is needed to properly abort in-flight DNS operations so the process can exit.

Will rebase after #33580 lands.

[fibibot]

Walking back my prior approval — the latest two commits regressed parallel/test-dns-channel-cancel.js. CI shows 9 consistent debug-shard failures (linux x86_64 + aarch64 and macos-aarch64) with the test taking ~20s and timing out:

test node_compat::parallel::test-dns-channel-cancel.js ... fail (20023ms)
1 failed of 913

Release builds pass (faster, finish before the test runner's deadline) and windows-x86_64 debug happens to squeak through, but the substance is the same regression on every platform.

Root cause

Commit c2e391d5 "remove short hickory timeout" deletes this block from op_dns_resolve:

// REMOVED in this PR:
if cancel_rid.is_some() {
  opts.timeout = std::time::Duration::from_secs(1);
  opts.attempts = 1;
}

That block was added by #33580 (now merged on main, which is why this PR's merge-from-main brought in the cancel test) specifically because core.tryClose(cancelRid) aborts the awaited op but does not actually abort hickory's background resolver task — hickory keeps retrying for timeout × attempts after cancel. With the default config (5s × 4 = 20s), resolver.cancel() returns control to JS quickly but the resolver burns CPU/sockets until natural timeout, which is why this test runs for 20s and then trips the per-test deadline.

The PR description says "single ANY query replacing the 11-parallel-query workaround" — that's the right substance. But removing the cancel-time timeout fallback is unrelated to that change and is what regressed cancel.

Secondary smell

Independent of the above: the new retry loop in #query catches Interrupted and continues to the next attempt:

} catch (e) {
  if (e instanceof Deno.errors.Interrupted || e instanceof Deno.errors.TimedOut) {
    if (attempt < tries - 1) continue;
    code = "ETIMEOUT";
  }

Each loop iteration creates a new cancelRid, so resolver.cancel() only closes the rid that was registered when cancel() ran — the next iteration's fresh rid isn't in #cancelRids yet. Result: cancel aborts the current attempt but the loop happily starts a new query with a new rid that nothing has signaled. Pragmatically this gets swallowed by the timeout fallback fix above, but it's worth distinguishing Interrupted (don't retry — user cancelled) from TimedOut (do retry — c-ares semantics).

Fix direction: restore the cancel-handle timeout shrinking in op_dns_resolve (or split Interrupted / TimedOut handling so Interrupted exits the loop). Either alone should turn the cancel test green; doing both is cleanest.

Substance of the resolveAny rewrite is still right (single ANY query, per-record recordType dispatch, validateMaxTimeout clamp). The regression is scoped to the cancel-timeout deletion.