Implement Peerstore

[l0k18]

Key to the health of a source routed network is the free flow of current and accurate metadata about peers on the network.

The peerstore is a collection of information about peers, libp2p by default creates a key/address binding that can be used by all peers, and via the kademlia DHT, using the libp2p publish/subscribe package, peers will share this data, and keep it in a disk-based store until the entries expire.

The last piece after completion of the sharing and searchable database, is a query interface for nodes to request records for lists of peers by their public identity keys. The pubsub will usually preclude this necessity once a device is online long enough to catch all the advertisments, but it is needed for anonymity-protected bootstrapping of new clients.

closes #5

[l0k18]

The existing badger data store used in the pkg/storage package is running v3 of badger, and irritatingly, the old pstoreds persistence layer is running an old version. The persistence layer needs to be upgraded to v3 first.

[l0k18]

Further, turns out the peerstore: pstoremem, and pstoreds, both store the libp2p.Host private key in cleartext.

The existing seed node implementation code now initialises the Listener in order to run the libp2p.Host, and the options.Default() function (inside pkg/util/options has been extracted so tests and later, relay and client services all have correct and secure persistent data storage that isn't exposing secrets on disk.

Note for later, make sure that any code that fetches this key, that we have control of, zeroes the memory the record is fetched into. The libp2p codebase should also be audited to see how it handles secrets, since the data store is plainly not properly implemented in this respect.

This is now all handled correctly for tests and will be ready to correctly handle both client and relay uses for these identity keys.

A key change protocol for this key needs to be added, also, probably a longer TTL cert.Act with the key-change details as a new type of ad to propagate a key migration, which should be able to be triggered on demand (defcon one) to terminate any malicious use if the key is leaked somehow, a concern when many relays will be remotely operated. The pkg/seed module has a remotely accessible unlock protocol, which can further help to maintain the hot key without having it stored anywhere except in memory, without encryption.

This protocol will also need a HD keychain for the client side, ideally something that won't be hard to connect to a hardware enclave or airgapped master key to make key-rollover simpler and not immediately require a fully new private key.