The `pages` job works.  We might consolidate this later,
also e.g. drop the doc dependencies from the default image
if we won't really use that image for docs anymore.

Ideally we'd expand it as needed, but that seems relatively complicated,
so for now let's go big with the sparse file and allow to override.

In particular, log them with `[rules ]` instead of `[cache ]`

When inserting rules from a config file, process everything
in a single transaction to avoid using inconsistent sets of rules,
especially in a different instance and/or in case some error happens.

Also fix some over-eager assertions (CHECK_RET).

The new reports are:
./lib/rules/api.c:301:3: warning: Memory copy function overflows destination buffer
         memcpy(key_data_ruleset_end, &KEY_EXACT_MATCH, sizeof(KEY_EXACT_MATCH));
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./lib/rules/api.c:506:2: warning: Memory copy function overflows destination buffer
 memcpy(key.data, &KEY_EXACT_MATCH, sizeof(KEY_EXACT_MATCH));
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./lib/rules/api.c:699:2: warning: Memory copy function overflows destination buffer
 memcpy(key.data, &KEY_ZONELIKE_A, sizeof(KEY_ZONELIKE_A));
 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings generated.

I re-checked those places, and I believe they can never overflow.
I regularly run with ASAN as well, which would catch overflows.
I can't see a simple way of amending the code in a way
that the linter might be happy.

Forwarding-related changes uncovered this case
in integration.iter_limits test.  Errors can happen also
when consuming data produced by cache, in which case there's
no suitable server to blame for the error.

We planned it that way for the new config schema - and, why not.

Typical use cases should work now, briefly tested:
 - forwarding all to a resolver
 - forwarding a subtree downgraded to insecure (to resolver or auth)
 - forwarding a subtree to auth without changing DNSSEC chain (atypical)

In some places we need to repeat kr_make_query()
The issue is that some of its inputs (e.g. STUB/FORWARD, zone cut)
are now not known at the beginning of PRODUCE yet.
Also, checking that QNAME matches is useless on a cached reply.

I know that moving code makes e.g. blaming harder,
but this was a really long file now.
This commit _only_ moves code, except for nits:
- minor pieces moved into an -impl.h shared by both resolve*.c
  There a couple functions changed to non-static or static inline.
- order is preserved, for now at least

Two main use cases are actual RPZ file
and also the /local-data/records string (plain RRsets).

The RPZ semantics isn't very close to the specs,
but I believe the practical usability is already better
than our old RPZ implementation, thanks to following CNAMEs.

(internally at least, not in api.h yet)

They're a bit weird but RPZ has something close to them.

It's questionable which SOA owner to use, but some users will surely
prefer NXDOMAINs to empty zones.

Merge from master resulted in decrease by one; no idea why.

Example:
  assert(require('ffi').C.kr_view_insert_action(
  		'127.0.0.0/24', 'policy.DENY_MSG("message")'
	) == 0)

Also switch the localhost rule there, finishing migration
of all special names from the policy module.

fixes modules/dns64 test

Picked up old work, rebase-squashed after many months;
then fixed up a little as needed in this newer version.
(and later many minor fixes got squashed in)

See NEWS for 4.0.0: "always send DO+CD flags upstream".

We already had rank stored in there, in particular
entry2answer() always stored it.

- kr_layer_t isn't really useful in the inner functions
  (it's mainly useful through ->state when returning from layer)
- kr_query seems a little more suitable to pass than kr_request