KES agent integration

[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.

[tdammers]

Changelog needs to be fixed, rest looks good.

[tdammers]

Why the extra spaces?

[tdammers]

Suggested change

	specifies how to obtain the actual credentials (OpCert and KES SignKey). For
	now, the only supported method is passing an OpCert and an
	UnsoundPureSignKeyKES, presumably loaded from disk
	(`PraosCredentialsUnsound`); future iterations will add support for
	connecting to a KES agent.
	specifies how to obtain the actual credentials (OpCert and KES SignKey).
	Two methods are supported:
	- Directly passing an OpCert and an UnsoundPureSignKeyKES, presumably loaded
	from disk (`PraosCredentialsUnsound`)
	- Passing a socket address to a KES Agent from which OpCerts and (sound)
	SignKeyKES can be obtained (`PraosCredentialsAgent`)