resolved: refactor DNSSEC answer validation

resolved: refactor DNSSEC answer validation

This changes answer validation to be more accepting to unordered RRs in
responses. The agorithm we now implement goes something like this:

  1. populate validated keys list for this transaction from DS RRs
  2. as long as the following changes the unvalidated answer list:
    2a. try to validate the first RRset we find in unvalidated answer
        list
    2b. if that worked: add to validated answer; if DNSKEY also add to
        validated keys list; remove from unvalidated answer.
    2c. continue at 2a, with the next RRset, or restart from the
        beginning when we hit the end
  3. as long as the following changes the unvalidated answer list:
    3a. try to validate the first RRset again. This will necessarily
        fail, but we learn the precise error
    3b. If this was a "primary" response to the question, fail the
        entire transaction. "Primary" in this context means that it is
        directly a response to the query, or a CNAME/DNAME for it.
    3c. Otherwise, remove the RRset from the unvalidated answer list.

Note that we the too loops in 2 + 3 are actually coded as a single one,
but the dnskeys_finalized bool indicates which loop we are currently
processing.

Note that loop 2 does not drop any invalidated RRsets yet, that's
something only loop 3 does. This is because loop 2 might still encounter
additional DNSKEYS which might validate more stuff, and if we'd already
have dropped those RRsets we couldn't validate those anymore. The first
loop is hence a "constructive" loop, the second loop a "destructive"
one: the first one validates whatever is possible, the second one then
deletes whatever still isn't.