Regularise era based command structure

[newhoggy]

Changelog

- description: |
    Regularise era based command structure
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  - improvement    # QoL changes e.g. refactoring
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

The main change in this PR is to change command parsers to return Maybe (Parser a) instead of Parser a.

This is based on the principle that commands themselves should determined whether they exist in a given era. This principle is used in the new Conway commands and will see more use in the future.

Requiring that all command groups accept Maybe (Parser a) will mean that any new or existing commands can become era-sensitive without inducing refactoring. As it is at the moment if a command needs to become era-sensitive, the parent command group will need to be refactored to accomodate it if it doesn't already which is the case for a number top-level commands groups.

The PR also contains a small number of help text fixes.

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
  • round trip tests
  • integration tests
    See Running tests for more details
• 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
• The changelog section in the PR is updated to describe the change
• Self-reviewed the diff

[Jimbo4350]

I don't think this is necessary as these commands will be available in every era unless e.g the crypto changes.

[Jimbo4350]

I'm not sure I understand the reason for this change.

[Jimbo4350]

Why the change from asum?

[newhoggy]

asum is in the implementation of subInfoParser so we are still calling asum indirectly:

subInfoParser :: String -> InfoMod a -> [Maybe (Parser a)] -> Maybe (Parser a)
subInfoParser name i mps = case catMaybes mps of
  [] -> Nothing
  parsers -> Just $ subParser name $ Opt.info (asum parsers) i

subInfoParser is used instead so that commands are self-describing. Previously the implementation of the parent command group provided the description.

[Jimbo4350]

👍

[Jimbo4350]

Why the change from Parser (..) -> Maybe (Parser (...))

[newhoggy]

The change represents a shift of responsibilities.

Previously it was the parent command group that decides whether the command should appear in an era.

The change shifts the responsibility from the parent to the command in question. ie the command itself determines whether or not it should show up in a given era.

This is already how it is done for the governance commands and some other commands.

The purpose of this PR is to harmonise our code base to consistently use the latter convention.

[Jimbo4350]

Some questions

Respond to question