Design - Networking - TLS Key Rotation

**Entities Needed in the TlsFactory**
1. All public keys in a public trust store.
2. The public and private agreement key pair
3. The agreement certificate.

**Current Implementation**
* Node Does Not Load Keys From Disk
1. The agreement certificate is rendered from the private public key pairs of the agreement keys and the signing keys
2. The signing key acts as the root certificate authority.
* Node Loads Keys From Disk
1. All private keys are read from a private key store on disk.
2. All public keys and certificates are read from `public.pfx`
3. We assume (require) that the agreement certificate loaded from `public.pfx` has the signing key as the root certificate authority.

**Future Implementation**
1. All public keys of other nodes are received through HAPI transactions in the Application and then provided to us through the ConsensusRoster
2. Each node, when it discovers it's public keys have been rotated in the ConsensusRoster, loads new private keys from disk.
* How do we validate the private keys loaded match the public keys?
* How do we handle failure to load new private keys?
* This seems fatal, the node operator is going to have to provide the correct private key, which if they don't have may require submitting a new transaction with a new public key. The node will just be out of commission and have to do a reconnect once it has been properly keyed.
3. Once the proper keys have been loaded, the TlsFactory will have to be re-keyed with the new key stores and the network connections restarted for the nodes that have has their keys rotated.

**Goals**
1. key rotation of 1 node without restarting all nodes.
2. key rotation without restarting the node with the keys being rotated.
3. key rotation without breaking connection between nodes that have not had their keys rotated.
4. Nodes which have not been re-keyed to match their public keys fail to establish network connections once the new ConsensusRoster becomes effective.

**Complications**
1. A node will not be able to reconnect without being properly keyed.
2. Genesis
* A node will need a ConsensusRoster with enough overlap with the current ConsensusRoster used by the network to be able to perform a reconnect
* The node will need to be keyed to be compatible with the current ConsensusRoster on the network, meaning other nodes have to have the public keys that match the private keys of the genesis node.

The completion of this ticket should result in formal documentation that is stored in the repo. This documentation shall be maintained if the implementation needs to change.