... even if only building

Fixes https://gitlab.labs.nic.cz/knot/knot-resolver/issues/248

We pushed all authority to the wire, but that was unnecessary,
and in particular it clashed with not validating NS in authority when
forwarding (new change).  Let's only apply this to NSEC* RRs.

Sometimes I was getting huge RTT numbers in the output (>4G).

It's not very nice that this symbol used in hints.so is defined in
sbin/kresd, but it touches the daemon structures and thus doesn't
really belong into libkres.

"lua_" in name is not appropriate, as the function does no lua stuff
anymore, so let's unify it to "engine_".

Next time it will be directly visible what record fails to validate,
which was the most time-expensive part when creating the parent commit.

Fixes https://gitlab.labs.nic.cz/knot/knot-resolver/issues/248
Some (exotic?) resolvers add extra NS records but doesn't provide
signatures for them even though we ask with +dnssec +cd.
That lead to validation errors.  Current example server: 198.101.242.72
Let's not try to validate them when FORWARDing, as we won't most likely
need those records anyway (contrary to iteration mode).

It's needed after the parent merge (sometimes, e.g. on macos).
We always depended on it through libdnssec, so it's no real difference.

- move it to utils.c, so it's sensitive to later changes in verbosity
- don't mark the lines with [tls], as they may come through libdnssec
- use stdout like other verbose messages, instead of stderr (real errors)

- expose the function as hints.root_file
- use the same filename as Debian
- remove the unneeded script
- docs and some nitpicks

Limit maximal resolution time

Closes #241

See merge request !368

Production kresd should compile with -DNDEBUG, so it wouldn't be
affected by this, but it was annoying for debugging other problems.
See https://gitlab.labs.nic.cz/knot/knot-resolver/issues/245

Fixes https://gitlab.labs.nic.cz/knot/knot-resolver/issues/240

In particular, don't keep even a reset read-only transaction.
This doesn't help with that MDB_BAD_TXN, but still it seems better.

The locking was done incorrectly - the copied text from man open(2)
suggested creating a *unique* file and linking that one to the lockfile.
Anyway, I don't think we need to support cache on NFSv3 on old kernels ;-)