Implement kes-period-info command

[Jimbo4350]

Resolves: #2551, #3257, #2558, #3556

Implement kes-period-info cli command that checks your operational certificate and certificate issue counter file are correct:

> cardano-cli query kes-period-info --testnet-magic 42  \
    --op-cert-file example/node-pool1/shelley/node.cert \
    --operational-certificate-issue-counter-file example/node-pool1/shelley/operator.counter
✓ The counters match what is in the node's protocol state
✓ The counters in the operational certificate and operational certificate issue counter file are the same
✓ Operational certificate's kes period is within the correct KES period interval
{
    "qKesNodeStateOperationalCertificateNumber": 6,
    "qKesCurrentKesPeriod": 404,
    "qKesOnDiskOperationalCertificateNumber": 6,
    "qKesRemainingSlotsInKesPeriod": 3760228,
    "qKesMaxKESEvolutions": 62,
    "qKesKesKeyExpiry": "2022-03-20T21:44:51Z",
    "qKesEndKesInterval": 434,
    "qKesStartKesInterval": 372,
    "qKesSlotsPerKesPeriod": 129600
}

It checks:

• The counters in the operational certificate and operational certificate issue counter file are the same.
• The counters match what is in the node's protocol state
• The KES period in the operational certificate is correct (based on the current slot).

[newhoggy]

I did some more testing just now and am a little bit concerned about the presentation of the command:

For example when I run this against my stake pool:

CARDANO_NODE_SOCKET_PATH=... cardano-cli query kes-period-info --mainnet --op-cert-file node.cert --operational-certificate-issue-counter-file node.counter
Command failed: query kes-period-info  Error: Node operational certificate at: node.cert has an incorrectly specified KES period: 386 The correct KES period is: 389

I think if the KES period is behind, it is noteworthy, but not necessarily wrong to warrant an error.

For example a SPO might be worried their stake pool is not producing blocks, and try to use the command to verify if they've cycled their keys incorrectly. The command gives them an error that makes them feel like they've cycled their keys incorrectly, but they actually did it correctly, but they were just unlucky to not have produced blocks and the KES period is different only because the SPO is doing the query a few KES periods past when they cycled their keys.

Not sure if it's possible, a useful thing would be printing when the current KES keys will expire.

I think a good UI might look like this:

$ CARDANO_NODE_SOCKET_PATH=... cardano-cli query kes-period-info --mainnet 
 ✓ The counters in the operational certificate and operational certificate issue counter file are the same.
 ✓ The counters match what is in the node's protocol state
 ✓ The KES period in the operational certificate is correct and started on Thu 16 July 2021 01:45:18 AEDT
 ✘ Warning your operational certificate expires in two days on Fri 16 Jan 2022 01:45:18 AEDT

[Jimbo4350]

I think if the KES period is behind, it is noteworthy, but not necessarily wrong to warrant an error.

For example a SPO might be worried their stake pool is not producing blocks, and try to use the command to verify if they've cycled their keys incorrectly. The command gives them an error that makes them feel like they've cycled their keys incorrectly, but they actually did it correctly, but they were just unlucky to not have produced blocks and the KES period is different only because the SPO is doing the query a few KES periods past when they cycled their keys.

I definitely agree with the UI change, it should be diagnostic.

[Jimbo4350]

bors r+

[iohk-bors]

Build succeeded:

• ci/hydra-build:required
• buildkite/cardano-node

[wutzebaer]

Wohoo whan will it be released?