current processed query is always in `request->current_query`

when no validation is attempted, trust level is 'bad'
when validation attempted but insecure, trust level is 'insecure'
otherwise 'secure'

minimised nodata/nxdomain can now be cached if it is
authoritative. also pkt/sec cache are now shared using
the ‘rank’ field to replace insecure version with secure
if needed

this is a workaround for missing DEFER operation, as the
validator module can only detect trust chain breakage
(caused by answering from different authority) after the
iterator writes answer. this causes duplicated answer on
uncached queries

this doesn’t fix record duplication in answer when not answered from cache

if the query has RD=0 or is ANY, only cache is probed
for ANY, only A/AAAA/MX is checked and no query is
forwarded to the authoritatives

if the answer is flagged as insecure, it means that the resolver tried
to validate it, but couldn't (e.g. trust chain doesn't exist)

the key is now stored in a format friendly to prefix search, the values
also contain one more 16bit field to store rank of the data (to be
utilised later)

this is a problem when both CNAME and the target are answered from the same NS (but different authority), but only the CNAME authority does DNSSEC. it’s probably legal, but it’s pretty stupid to do so

refs #33

the selected address is now an array with selection, caller can then send the same query to multiple offered targets

refs #35

this could happen if the query contained a CNAME with AA=0, or missing mandatory DS in previous NS query

this is useful if we want to prefetch or update data
in cache, it doesn’t affect the lookup of closest known
zone cut

if the client doesn't support DNSSEC, scrub these from the answer
and do not set the AD bit

until RFC2181 credibility is implemented in cache, this behavior breaks
DNSSEC as the parent-side comes first to the cache
disabled this behavior until implemented properly

RRSets are merged by using stash_add().

this fixes a case when a DNSKEY is either accepted from cache or offered
in advance

a cache is consulted before we even know a zone cut for the query, thus
the DNSKEY can't be validated. as a policy, everything should be
validated before it's accepted into cache, then it's trusted and
shouldn't be rechecked

with DNSSEC, such query needs to be revalidated as the TA/key is missing
for the new zone cut, which would lead to duplicated answers

in the future there may be an api to defer query processing, but for now
it can't be done

in this case the NS is an authority for both parent and child, so the NS
set stays the same and only the cut name changes

this fixes problems with servers authoritative both for
parent and child zone and vice versa
as the DS is authoritative parent-side, a full subrequest
is launched. this breaks some tests that don’t have
a full referral path

todo bugs:
- non-existence proof with only SOA and no NS is not
correctly resolved
- revalidation in some cases causes record duplication
- NS queries with DO=1 answered from cache are not correctly resolved, as the TA is not set at this time