Made TxBody a data family

[Soupstraw]

Description

This PR changes TxBody from a type family to a data family.

close #4999

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.

[teodanciu]

Can we just remove these types ShelleyTxBody... ConwayTxBody without deprecating them?

[Soupstraw]

I suppose I could add type synonyms to address that issue.

[Soupstraw]

It's not so easy actually, when I try to deprecate the type synonym, it deprecates the pattern with the same name instead..

[teodanciu]

I just realized that these types are not exported in the API, so maybe it's not a big deal to remove them?

[neilmayhew]

This is a welcome simplification, and the concretisation of era in many places to a specific era removes a lot of noise and complexity.

Could the same technique be applied to some of the other abstract types that we have, such as TxOut and TxCert? If not, what's special about TxBody? And if we can do it only for TxBody then perhaps it makes the code more confusing since TxBody is then handled differently to the way we handle all the other era-specific types.

I'm also concerned that removing the era parameterisation in some places will reduce the reusability of the code. OTOH, since we already know now that things from earlier eras aren't going to be reused, perhaps it's good that we remove the complexity of that unnecessary reusability.

[neilmayhew]

Removing the era from the raw tx bodies removes a lot more constraint noise. Nice!

[Soupstraw]

@neilmayhew What makes TxBody special is that so far we have defined a new TxBody for pretty much every era. By making TxBody a data family, we improve type inference and also it makes it possible to pass TxBody as a parameter with the kind Type -> Type. With a type family you had to wrap the type family in a newtype to be able to do that.

The drawback of having a data family here is that now if we want to reuse a TxBody from a previous era, we'll have to redefine the datatype and write all the instances, but if we add an entirely new TxBody, then we have to do that anyways.

[teodanciu]

Looks good to me.
I think we should definitely mention in the changelog of each era the removal of <Era>TxBody type, and since the Raw types are also exposed, the fact that we removed its era parameter.