- ensure gnutls logging can be turned on/off by using GNUTLS log group
- keep TLS / TLSCLIENT as log groups for our TLS logs and use GNUTLS
  instead

It's better to use separate log group, to separate between logs that
come from the lua module vs native C implementation. It is also more
descriptive, since http modules is used for other stuff besides its
deprecated DoH.

Plural makes more sense to me here, since it can take a table with
multiple entries as input.

Besides testing the API, running this test also ensures all log groups
have been properly defined (as long as kr_assertions are turned on).

To ensure all log groups have been properly defined, iterate over the
entire enum. If a value is missing, assert will be triggered.

Also fixes groups with number >=32 (32bit value was used to test
whether group is set before).

This serves two purposes:

1. As a utility logger during development.
2. As the last entry in enum - to make iteration over the values
   possible. Changing the value of LOG_GRP_DEVEL shouldn't be an issue,
   since it shouldn't be used in production code.

Add space padding when printing the group name to allow usage of
regular group names in lua code (e.g. "io" instead of "io    ").

The function returns a table where key is the group name and the value
is either true (when logging selected group), or nil (when group isn't
selected).

This replaces the list_log_group() which didn't really work.

Ensure both these functions return string that represents the log level.

Also avoid using printf - it'd probably break API when using map().

I think notice is a good default - it should be used for scarce messages
that the user should see, while info level provides more low level info.

It could make sense to increase the log level to info if running with
journalctl (but it might be overkill).

daemon/session: fix an issue with timers

See merge request !1195

The practical problem was also mitigated by libuv >= 1.32.0 (2ee2d46)

utils/cache_gc nit: use dynarray from libknot 3.1

See merge request !1194

It's compatible, so the only real effect is avoiding compiler:
warning: "DYNARRAY_VISIBILITY_PUBLIC" redefined

support Knot DNS master (3.1)

See merge request !1192

The go stuff probably never worked on buster and we just forgot to test.

This part is fully compatible with 3.0, fortunately.
It was insufficient inclusion on our side anyway, working by accident.