The _try_ functions additionally return positive values on success,
and the code around didn't deal with that.

So far there's no evidence that this caused any issues beyond debug-logs:
  [prlayr] ... iteration of group ... ended with status 'Unknown error ...

As with some other aspects, these DNAMEs do not work exactly as
in a real zone, e.g. they don't cause occlusion.

We have it, but it probably adds more confusion than use to mention it here.

I'm not aware of a use case for the limits to be equal,
but it's at least a sane combination.

So far we don't know how to fix this.

Oto Šťáva authored 6 months ago and Vladimír Čunát committed 6 months ago

This is a `pandoc` conversion with just a couple tiny manual modifications.

Let's assert that we don't run over the edge.
If I look right, so far we don't use this in a way 
that this could happen, and I can't see how it would make sense.

In case of no error, the index is returned,
but `int` isn't a great choice for returning array indices.
(though I doubt that we can get anywhere near 2^31 elements in practice)

Detected by Coverity.

Strictly speaking, the .ip member is on 16 bytes long,
so it doesn't suffice in case it's an IPv6.
Practically it doesn't matter, as there's the union containing all this.

Either way, I think it's cleaner to copy to the whole union.
Also we don't support it in this case,
but theoretically e.g. an AF_UNIX could happen,
so let's be defensive and guard by kr_require().

We need to check the "< 0" condition *before*
incrementing or decrementing the returned layer_ix.

Detected by Coverity :-)

- poe check: check for difference in JSON schema
- scripts/meson/make-doc.sh: do not create JSON schema

manager: python modules reorganization

See merge request !1598

Old knot_resolver module is now knot_resolver_build_options.

Old knot_resolver_manager module is now just knot_resolver.

- statistics.py: removed
- metrics: prometheus support is in separate module

- new KresManager exception
- imports formatting

Since we support python 3.8 and higher, there is no need for backwards support for most of the features we use in the standard typing library.