1. validate module must be between iterate/cache
2. produce: copy OPT with DO=1, ask for DNSKEY if we don’t have it
3. resolve.c: subrequest DNSKEY if asked to do it
4. consume: check DNSKEY and set it, validate RRSIGs against it

another issues:

rrsigcache is copypasta of rrcache, there is one special case with storing RRSIGs which doesn’t deserve it’s own module (if the validation is off, then nothing will get written in there anyway)

since the resolution is asynchronous, layers must only *ask* resolver to do subrequests for them using query flags (like when we encounter an unknown zone cut)

fixes potential cache key oob write

previously a CNAME RR could be merged as a queried type RR, leading to failed cache lookups as ‘expired’

the cache_peek() api was reworked to return an error code instead, from this the caller can tell whether the record is present (but expired) or missing. this save a secondary CNAME lookup in case the original record was just expired

prevents pointless caching of TTL={0,1} records

if an authoritative answer comes and the server responds correctly, but appends out-of-bailiwick NS records, ignore them but resolve the query

since the zone cut is looked up after layers now, it
is pointless to search for minimized names from cache,
since this is the same operation as searching for a zone cut

this prepares cache/txn structures to hold API as well, so we can get
rid of the global api

this fixes a regression when a final name has a dependency with a short
TTL in the search path, but has longer TTL itself
in another words - if there's a CDN in the middle and the name doesn't
exist, answer it from the cache without requerying the CDN

This reverts commit 3d1ee641.

previously only queried names were resolved from cache, this meant that if the target name was present in cache but a server on the search path dropped from it, it would refetch it - this is a problem when a loadbalancer with very short TTL was in search path

module api can now store userdata, e.g. owner

previously producers in overlay could only generate query or
update the final answer - this required exported callbacks
from iterate.c and specific processing. this wouldn’t work
for negative cache, as it would be required to reimplement
whole iterate layer for cached data

the new workflow allows produce layers to generate answer
instead, this answer is then consumed in the next step
by the iterate module in unified fashion for all caches/generators

each asset is tagged by a byte defining its type and importance
this is a groundwork for negative cache and packet cache
abstracted the code in preparation for different backends

the reason is that LMDB allows only 1 write transaction
per thread, and this doesn’t work well with multiplexed
requests. there is probably going to be some performance hit,
but now transactions are scoped for each cache operation