Remove Shelley style certs in Dijkstra era

[Lucsanszky]

Description

Resolves #4963

Checklist

• Commits in meaningful sequence and with useful messages.
• Tests added or updated when needed.
• CHANGELOG.md files updated for packages with externally visible changes.
  NOTE: New section is never added with the code changes. (See RELEASING.md).
• Versions updated in .cabal and CHANGELOG.md files when necessary, according to the
  versioning process.
• Version bounds in .cabal files updated when necessary.
  NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
• Code formatted (use scripts/fourmolize.sh).
• Cabal files formatted (use scripts/cabal-format.sh).
• CDDL files are up to date (use scripts/gen-cddl.sh)
• hie.yaml updated (use scripts/gen-hie.sh).
• Self-reviewed the diff.

[Lucsanszky]

@Lucsanszky Could you explain, for the benighted - what the deal is with EraSpecificSpec class ? I can see that each era accumulates the "era specific" ones from the previous ones, for alonzo: shelleyEraSpecificSpec >> alonzoEraSpecificSpec, for babbage: shelleyEraSpecificSpec >> alonzoEraSpecificSpec >> babbageEraSpecificSpec, for conway: shelleyEraSpecificSpe >> alonzoEraSpecificSpec >> babbageEraSpecificSpec >> conwayEraSpecificSpec

The raison d'etre of the EraSpecificSpec class is to allow us to conveniently select specs and tests to run per era. It is @lehins's brainchild and it was necessitated by deprecating certificates without deposits post-Conway. Pre-Conway, certificates didn't have deposits, Conway introduced certificates with deposits and post-Conway we will only allow certificates with deposits. This caused some calamity in our current Imp test setup, where in each era we also run the Imp tests from previous eras. My first iteration merely ripped out the parts that breaks post-Conway and made sure that we don't run certain tests in certain eras. However, this is not a well-organised solution and is prone to oversight in the long-run. This typeclass approach suggested by @lehins is clearer and it is also a well established pattern in our codebase.

Is the semantic of eraSpecificSpec: the tests in these functions should be used in future eras? So are they technically specific for all eras? How does this relate to how we are already including the Imp from previous eras when running Imp tests? (for example, Babbage Imp module calls AlonzoImp.spec @era when defining spec)

I must admit, EraSpecificSpec was a very poor choice of name on my part. Fortunately, @lehins is already cooking a PR which among other things will also address the unfortunate naming. To answer your question, the semantic is more along the lines of what I described above: you can select which tests (collected by the functions) to run for the given era, when providing an instance for that era. Essentially, we will be able to mix and match conveniently in an organised way from here on out. I think the best way to explain or demonstrate what this does is by comparing the EraSpecificSpec instance of ConwayEra and DijkstraEra. In case of the ConwayEra we run all the eraSpecificSpecs from previous eras, whereas in DijkstraEra we stop running those tests altogether, essentially saying: "Only run these tests up to Conway". However, it is worth noting that with the current setup, we could also say things like "Only run tests from Shelley and Alonzo". Surely enough, we could achieve this behaviour without creating a typeclass for it, but this typeclass solution yields better organisation. Not to mention, that the compiler will yell at us if we forget to provide an instance for an era.

And where is the eraSpecific method used? I can see it used in shelley Imp, but not anywhere else, but perhaps I'm just missing it.

Yes, because we only need to use it there. As you pointed out, each Imp spec calls the previous era's Imp spec. This, combined with the fact that we are providing EraSpecificSpec instances for all the eras yields that even when we are in Conway for example, eraSpecificSpec will be evaiuated but it will pick the implementation defined in the EraSpecificSpec ConwayEra instance, which in our case is:

  eraSpecificSpec =
    ShelleyImp.shelleyEraSpecificSpec
      >> AlonzoImp.alonzoEraSpecificSpec
      >> BabbageImp.babbageEraSpecificSpec
      >> conwayEraSpecificSpec