Generate fields only if they make sense for the given era

[newhoggy]

Description

Introduce the FeatureInEra type class. This type class will be used by "feature" types to define a way to determine if that feature is supported in an era.

Introduce the FeatureValue type. This type is meant to be used to define data types with era-sensitive type-safe fields.

This PR does not yet use FeatureValue to implement type-safe fields for the ProtocolParameter type because doing so requires that ProtocolParameter take an era type argument, and there are challenges to doing that as this time.

The changes to introduce type-safe fields will be introduced in #39 when some other issues have been resolved.

More explanation is made inline.

Changelog

- description: |
    Generate fields only if they make sense for the given era.
    Changes:
    - New `Cardano.Api.Feature` module
    - New`FeatureInEra` type class
    - New `FeatureValue` type
    - New functions:
      - `genFeatureValueInEra`
      - `featureInShelleyBasedEra`
      - `isFeatureValue`
      - `valueOrDefault`
      - `asFeatureValue`
      - `asFeatureValueInShelleyBasedEra`
    - `genProtocolParameters` and `genValidProtocolParameters` functions take additional `era` argument
  compatibility: breaking
  type: feature

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• The change log section in the PR description has been filled in
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • roundtrip tests
  • integration tests
    See Runnings tests for more details
• Any changes are noted in the CHANGELOG.md for affected package
• The version bounds in .cabal files are updated
• CI passes. See note on CI. The following CI checks are required:
  • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
  • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
  • Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7
• Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.

[newhoggy]

This is how to define a "feature". This is exactly the way we currently define features except the naming convention for them is "SupportedInEra". This PR proposes to use the word Feature in place of SupportedInEra because it is shorter.

[newhoggy]

Every feature defines a FeatureInEra type-class instance.

featureInEra uses the same convention as the function bool and maybe in the standard library in that those functions take the negative case before the positive case.

[newhoggy]

The main part of the PR is implemented here and similar.

We only generate values for fields if they make sense for the given era.

Note, this code is not yet type-safe because the type of protocolUpdateUTxOCostPerWord and protocolUpdateUTxOCostPerByte are both Maybe Lovelace and there is no defence against accidentally confusing the two in the code.

The intent is to eventually define these fields like this:

protocolUpdateUTxOCostPerWord :: FeatureValue ProtocolUTxOCostPerWordFeature era Lovelace
protocolUpdateUTxOCostPerByte :: FeatureValue ProtocolUTxOCostPerByteFeature era Lovelace

This would make the code type-safe because the code that checks the relevant feature for the field would not compile if they are accidentally mismatched.

Unfortunately this is not implemented here because doing so requires ProtocolParameters type to take an era type argument, but there are unresolved issues with making that change for reasons unrelated to this PR, but hopefully they can be resolved in consultation with the relevant people.

[newhoggy]

This function is not yet used because the relevant fields are not yet using the FeatureValue type, but it will be once that change is made (possibly in a future PR).

The advantage of having a genFeatureValueInEra is that using it is less error prone than exist practise which is to define per-feature generators manually. It is very easy to accidentally not return NoFeatureValue in the case where the feature is supported in the given era in implementation of those manually written functions and that bug currently exists in the code.

[newhoggy]

Having generators be era-sensitive improves our test coverage because we can now test across eras.