Js/tdammers/kes agent conectivity

[jasagredo]

This changes Consensus such that mlocked KES keys are used internally.

This is important groundwork for supporting KES agents in the future. In this form, the code will still load KES keys from disk, which is unsound, but the internal machinery is ready to also accept KES keys from other sources, and once loaded, KES keys will be handled appropriately (kept in mlocked RAM at all times, securely erased when expired).

This also involves a restructuring of the HotKey data structure, which now manages not only a KES SignKey, but also the corresponding OpCert. This is necessary for two reasons:

• With a KES agent, the OpCert will be provided along with the SignKey; this is the easiest way to make sure that the OpCert always matches the SignKey it is used with
• With the new structure, KES keys can be replaced in a live node kernel, without having to restart it and reload the entire configuration. Because of this, the HotKey, which manages the dynamic part of the node kernel's signing mechanism, needs to be able to replace not just the SignKey (which it already did, in order to handle key evolution), but also the OpCert (which will not change when a SignKey evolves, but it will change when a new SignKey is provided).

Supersedes #1284.

Issue #558.

This adds KES Agent connectivity to consensus.

To use a KES Agent to source KES SignKeys and OpCerts, the praosCredentialsSource in the PraosCanBeLeader data structure can now be pointed to a domain socket address where it will look for a KES Agent.

Also covers #1077.

[jasagredo]

Why is this doc stuff needed at all?

[tdammers]

SerDoc is a library for semi-automatically generating serialization documentation from types; this can then be used to generate documentation for typed-protocols. In a perfect world, we wouldn't need this here, but the KES agent protocols (or at least, some of them) are generic in the crypto, and if we want to be able to generate protocol documentation for those, we need to demand those SerDoc classes on them. This constraint then propagates up to the KES Agent API, and anything that uses it.
If this is a major complaint, I can restructure the code such that the protocols are no longer parametrized over the crypto, but always use the StandardCrypto. This would make it impossible to test the KES agent protocols against MockCrypto, but I don't think that would be a major concern to be honest.

[jasagredo]

My concern here is that we don't use SerDoc anywhere else, so even if it is a nice feature we might not leverage it in the end. Shouldn't some documentation be generated somewhere making use of this feature? Or couldn't this be attached to the kes-agent executable instead of to the library and used there to generate whatever docs you want, leaving Consensus free of these constraints?