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 Support for SCION UDP Sockets in rainsd, rainspub, and rainsdig #97
  • with TRC integration support Support for SCION addresses and PKI #11
  • with SCION address support Support for SCION addresses and PKI #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)