* package python3-libknot

 * add more autopkgtest tests
   - set up and run an authoritative resolver
   - do dnssec signing
   - validate the signatures

 * consider making the modules dynamic instead of static. i see three
   possible approaches:

   a) each module could ship in a separate package, and would drop
      into the path identified by --with-moduledir=
      (/usr/lib/$(DEB_HOST_MULTIARCH)/knot/ , currently). They would
      be automatically loaded by knotd as long as the packages were
      installed.

   b) we could ship them all directly in the knot package.  they would
      live in /usr/lib/$(DEBHOST_MULTIARCH)/knot-$(VERSION)/ in this
      case, and the admin would need to manually load them in
      knot.conf.

   c) we could ship them in a separate knot-modules package (one
      bundle of all modules, located in the same place as (b)).  the
      admin would need to manually load them in knot.conf.

   In either (b) or (c) we might want to change --with-moduledir to
   point to somewhere that the admin is encouraged to edit, like
   /etc/knot/modules or something.  or maybe we should abandon
   --with-moduledir entirely?

   Transitioning from static to dynamic modules seems like an awkward
   process, though.