Integrate KES Agent logs with logging system

[tdammers]

#1402 introduces KES Agent connectivity, allowing a block forging node kernel to receive KES credentials from a KES agent rather than loading them from disk.

This will generate additional log data, which should be integrated into the existing logging system.

Currently, the KES agent client in consensus just uses a nullTracer, ignoring any log data coming from the agent connection; this should be changed such that the log data is forwarded to the node-wide logging system.

[tdammers]

Question:

#1402, in its current state, provides the following information through tracers:

• KES agent interactions (connecting, disconnecting, receiving keys)
• Forge state events

The forge state already had cases for "cannot forge due to poisoned key", which essentially means "cannot forge because we don't have a key".

However, previously "poisoned" always implied that a key had been present, but is no longer valid; but when connected to a KES agent, it can also mean that no key has been received yet.

In order to reflect the difference, we would have to add a third state to the HotKey's KESKey type, allowing us to represent 3 states:

• Valid KES key
• Poisoned (we had a key, but it expired)
• NoKey (we never had a key, still waiting to receive one)

So the question is, is this necessary? Or is it enough to just report that we don't have a valid key, and leave it to the KES agent traces to indicate why?

[amesgen]

Thanks for pointing that out, I agree that a user seeing a message that their key is poisoned will likely mean that they assume that there is/was a key in the first place, which might no longer be true as you say.

So I think at the very least, we should rename things related to this and update the haddock (currently, i.e.

• KESKeyPoisoned (from KESState) to sth like KESKeyNoneUsable, both for when there is no key yet and when there is a poisoned/expired key.
• KESKeyAlreadyPoisoned (from KESEvolutionError) to sth like KESKeyAlreadyNoneUsable.

This might already be enough to point users in the right direction, but we could as you mention add a third state or add an additional Bool (or rather a new sum type) to KESKey(Already)NoneUsable to tell the user explicitly which of the two cases (no key, or a poisoned/expired key) they encountered. AFAICT, this would be a very small change, so I think it makes sense; we regularly enrich trace messages to make introspection/debugging easier.