Investigate paring down the codebase

[britram]

Define a set of features SCIONlab actually needs, and move utilities not part of that feature set into an alternate codebase. This reduces the maintenance load for the SCIONlab development team.

I think this looks like:

• rainsd
  • without reverse lookups
  • without consistency checks
  • without advanced heuristics for doing anything other than answering and caching queries
  • with UDP/SCION support #97
  • with TRC integration support #11
  • with SCION address support #11
• rainspub
  • with keyphase support
  • note that dual-key signing support is handled by an external zone manager, not part of this codebase. we assume SCIONlab will hook zone management of rainspub into an existing administation tool / administrative database.
  • with shard splitting support
  • with pshards
  • with checkpointing support (i.e. one should be able to run rainspub like certbot)
• rainsdig
  • optional, for debugging support, let's talk to SCIONlab

All the additional simulation and research stuff should migrate out to a separate repository, except features that are useful for system testing as in #100

[britram]

I'll do this as part of my engineering reviews in December, so assigning to self.

[britram]

next step is to create a rains-extras repo where all the extra stuff goes (at least at first)