Feat: key derivation for libp2p identities

[hsanjuan]

Keeping track of identities when setting up gateways is a pain.

This allows choosing a single secret for all gateways in a deployment, and then deriving individual keys based on a given index. It also allows painless key rotation.

Once we add bootstrap/peering capabilities, this functionality will be extended and gateways will generate peer IDs for other gateways, look them up on the DHT and peer with them automatically. That is, we will use the DHT for service discovery, skipping manual peering configuration altogether.

[AnomalRoil]

LGTM

[hsanjuan]

Per convo with @aschmahmann on "why would you do this???":

• The first and foremost reason is to simplify configuration management of a set of gateways by having a single secret to manage them all.
• To his follow up question: "you don't need even that, they could have perfectly random ephemeral IDs which is even less configuration":
  • Yes, and that is supported with the semi-ephemeral libp2p.key file.
  • But having persistent IDs allows:
    • To have stable peering arrangements (as needed) with other parties/parts of the infra
    • To have auto-peering among members of the gateway set (in the future) by leveraging routing information in the DHT for known PeerIDs.
      • This allows us to, for example, build a distributed quota management system on top.

Sure there are other ways and you could get away without stable peer IDs but key-derivation is a good compromise between not having stable peer IDs at all and needing to configure each machine individually and track keys all over the place.