Switch to new hickory-resolver release and harden security settings

[cr-tk]

Summary & Motivation (Problem vs. Solution)

This PR has three aspects:

1. Switch from hickory-resolver 0.24.4 to 0.25.2, and the significant transitive dependency changes that requires.
2. Adapt some API usage to be compatible with the new hickory-resolver version.
3. Turn on two DNS security hardening features.

The motivation for 1) and 3) are recommendations from a recent Trail of Bits audit of the qos_net component. The 0.25.x branch came out in March and has some notable improvements. Step 2) is a necessary side effect.

Via 3), we now enable opportunistic DNSSEC validation as well as case randomization, which helps under some circumstances.

For 2), it is now necessary to have an explicit Tokio runtime handle. We create it on the Proxy level, since instantiating it ad-hoc at the ProxyConnection level is too costly. Since we block synchronously on the (formally async) DNS request, threading should effectively work as it did before.

Note for the code reviewer: the Tokio runtime needs to drop to clean up resources. By my understanding, it will do so automatically once the struct Proxy does, but this may be worth double-checking.

Note for dependency security review: I haven't looked at the crate changes yet, and will document that in the comments.

How I Tested These Changes

Local tests.

Due to the changes to the DNS resolution behavior (notably DNSSEC usage), and potential related performance changes, this PR should have some regression testing in pre-prod environments before production usage.

If the proxy attempts to resolve a domain that has broken DNSSEC settings, we now expect this to fail. In most combinations, it would have failed already before this change (namely by the upstream resolver understanding DNSSEC and triggering a SERVFAIL on its own), but in theory this could now locally spot and reject problematic records that were previously accepted.

Pre merge check list

[cr-tk]

I've started on the dependency security review, see internal documentation.

[cr-tk]

This PR will require another rebase after #539 is merged.

[cr-tk]

@r-n-o @mark-nesbitt I've finished the dependency security review, see internal discussion and documentation.

[r-n-o]

Nice work!

[r-n-o]

Don't see this listed in the internal documentation, but this might be because it's already part of qos (in qos_enclave's Cargo.lock)

[r-n-o]

Same here: not listed in the sheet but fine given it's already in src/qos_enclave/Cargo.lock 👍

[r-n-o]

Thanks for the test coverage here!

[cr-tk]

@r-n-o thank you. As you already mentioned, crate versions that we already carry in trusted lockfiles are automatically trusted for changes in other lockfiles, and so aren't considered as a change of the trust situation (= not listed in the change set).

I can consider options for calling those out automatically, but I'll have to see if the corresponding addition of complexity in the tooling is worth it.

[cr-tk]

Also, for the record: c0aac25 avoids a footgun situation where DNSSEC is requested but not actually enabled. This is now reported and fixed upstream via hickory-dns/hickory-dns#3089.

hickory-dns/hickory-dns#3090 outlines the report and upstream bug fixes for a problematic edge case that we ran into during testing. Based on the developer's feedback, the corresponding fixes will likely only become available to us once we switch to future 0.26.x versions, and once those are stable enough for us. We'll have to see if this becomes relevant.