Testing and CI for internal components of rainsd / rainspub

[britram]

Implement testing with reasonable coverage, and add continuous integration for commits the repository, for implementation components of rainsd and rainspub.

Unit testing on individual components does not make a great deal of sense for most of RAINS, but adequate system-level testing coverage can probably be achieved by:

• creating a test root zone, a test TLD, and a test RLD (in testdata/)
• standing up a rainsd instance and publishing zones to it
• standing up a rainsd instance and preloading its cache
• standing up a second rainsd instance and pushing queries to it, so that it populates its cache from the first rainsd
• checking positive/negative responses to test queries against the list of expected results (with this test vector also to live in testdata)

Running this test three times using three different connection methods can fully exercise the switchboard, as well:

• via @fehlmach's simulation channels
• via local TLS/TCP/IP

ISTM a lot of the integration testing / simulation work can be repurposed to make this easier.

[britram]

Do this before #101: uncovered swaths of code might be ripe for paring down.

[britram]

Question: do we want this test to verify that things are cached in the second level, and how?

[britram]

Note: Use rainspub to publish to a bootstrapped authoritative server