Praos headers validation properties and generators

[abailly]

Description

This PR introduces generators, properties, and an executable to be able to QuickCheck Praos headers validation in a somewhat exhaustive and explicit way. Here is a brief summary:

• Generators produce GeneratorContext with various keys and parameters used in the forging of headers, and valid Praos Header StandardCrypto from such a context
• From a valid Header one can apply a Mutation that invalidates one particular rule for headers validation, using Generators too
• Header and GeneratorContext have JSON serialisers, with keys and bytes being output as base64-encoded strings
• the gen-header program can be used to generate a Sample of headers and context to be stored as part of a regression test suite, and to provide reference test vectors for other projects interested in validating headers

The JSON output looks like the following:

{
  "context": {
    "coldSignKey": "WCDQ24vfOrWlhgg65ZbHHxtyBt+QAGBoUx+IhgP1jYdHMg==",
    "kesSignKey": "WQJgmgx5dL86RoXLVEB18TH...=",
    "nonce": "ggFYII+ejLTnuete4jqw0uaCyPDzh1xOLhiTO/RSqyZ3v/wt",
    "praosSlotsPerKESPeriod": 9496,
    "vrfSignKey": "WEBzzMvKExinGbhtUaOcCMvRUw77NVnEfq85OV+MSvEb5m+NMN2tyMLgmaZNOhuAifLI3K/FQVZkEU8Rmb7A6EAj"
  },
  "headers": [
    {
      "header": "gooaAK6SORoAud8OWCA+ah5Aq6Nyw4uKwFeVWEMJ4Dw1tcOrDFFciVxibi06a...=",
      "mutation": "NoMutation"
    },
    {
      "header": "gooaAEIEphoA2MMuWCDqcIOxbDmAD0BU8mv3D7DauIjLAGG/o301UMqD5...=",
      "mutation": "MutateColdKey"
    },

TODO:

• Don't restyle existing files (added by @nfrisby)
• (deferred to other PR) Complete Mutation type to cover all kind of potential validation errors
• Include more components in the GeneratorContext (eg. stake distribution, KES period...)
• Add generate and validate commands to gen-header
• Add documentation
• Cover more Eras (?)

[nfrisby]

• Cover more Eras (?)

So far, headers are very much specific to protocols more so than era. Byron (RealPBFT), Shelley (TPraos), and Babbage (proper Praos) were the only eras that altered the protocol.

[abailly]

Thanks a lot @nfrisby for taking the time to review this draft, it comforts me this can be useful and gives useful directions to improve it. The reason for this comment about eras is that the code pretty much pins down the block header's era to Conway which might or might not be desirable.

[abailly]

Took me a while to have CI passing and fix some issues in the generators' logic but I think it's now ready for a proper review.
While the mutations do not cover all the validation logic, I think it's better to have a first partial version, and complete it in a later PR.

[abailly]

Any plans to merge this? It's CI green and I think I have addressed all reviewer's comments

[abailly]

@jasagredo I have removed changelog entry, but how do I prevent the CI from failing?

[jasagredo]

I mentioned it in the suggestion above. I have set the no changelog label now. Next time you push it will pass.

[abailly]

I mentioned it in the suggestion above. I have set the no changelog label now. Next time you push it will pass.

I understand, point is: I cannot do this. I would suggest finding another way, perhaps looking at commit messages, otherwise this will annoy external contributors.

[jasagredo]

Ah I didn't realize you couldn't do it. Indeed that is annoying for contributors hmmm. We will try to come up with a better solution.

[jasagredo]

Just some minor comments.

Also yesterday we discussed it in our meeting and you can actually just push an empty changelog fragment in your PR to go around the CI check. I think it makes sense as that says "I am declaring that this PR has no relevant changes worth to be included in the changelog".

[jasagredo]

You are required to sign your commits before I the PR can be merged.

[jasagredo]

The error in CI is a flaky tests that has not been flaky for a very long time and we are recently seeing more instances of it. Let's pray that the signed force-push makes it go away...

[abailly]

Ok, I will sign the commits