Update experimental api and propagate

[Jimbo4350]

Changelog

- description: |
    Introduce new `newtype UnsignedTx` type which aims to eventually replace `data TxBody`
    Introduce new `data Era` type which reduces the number of eras cardano-api exposes. It is only concerned with mainnet and the upcoming era
    Update experimental api and propagate 
    `BalancedTxBody` now returns `UnsignedTx` which is a wrapped cardano-ledger `Tx`. 
# 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
  # - refactoring    # QoL changes
  # - 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

Additional context for the PR goes here. If the PR fixes a particular issue please provide a link to the issue.

How to trust this PR

Highlight important bits of the PR that will make the review faster. If there are commands the reviewer can run to observe the new behavior, describe them.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[carbolymer]

Blocking to have more time to review. I'd like to to play with it a bit.

[carbolymer]

Why not reuse uninhabited types from Cardano.Api.Eras.Core? They're uninhabited types as well these, so they're not very useful on their own nor they are related to each other.

We could reexport them here for convenience.

Or the other way around, define them here, and reexport in old Api (might require moving to another module).
I think reusing type level tags will be much cleaner than introducing additional type families.

[Jimbo4350]

I don't want to do this to avoid confusion with the api we are deprecating. I want to keep the types separate.

[smelc]

Same concern as @carbolymer 👍

[Jimbo4350]

I think reusing type level tags will be much cleaner than introducing additional type families.

How will this avoid introducing additional type families?

[smelc]

Note that my comment was unrelated to the need/avoidance for additional type families. I'm concerned by symbols having the exact same name, that are going to be disambiguated with different imports; and I suspect this will confuse both us and users (even more for the latter).

[Jimbo4350]

Thinking about it some more I agree. We can re-use the types.

[carbolymer]

The type on the right hand side isn't really ShelleyBasedEra but just type level tag. I'd drop the Sbe part. For example:

Suggested change

	type family AvailableErasToSbe era = (r :: Type) | r -> era where
	AvailableErasToSbe BabbageEra = Api.BabbageEra
	AvailableErasToSbe ConwayEra = Api.ConwayEra
	type family FromExperimentalApiEra era = (r :: Type) | r -> era where
	FromExperimentalApiEra BabbageEra = Api.BabbageEra
	FromExperimentalApiEra ConwayEra = Api.ConwayEra

[Jimbo4350]

#604 (comment)

[carbolymer]

I don't understand the naming here. Maybe something more obvious:

Suggested change

	type family ToConstrainedLedgerEra era = (r :: Type) | r -> era where
	ToConstrainedLedgerEra BabbageEra = Ledger.Babbage
	ToConstrainedLedgerEra ConwayEra = Ledger.Conway
	type family LedgerEra era = (r :: Type) | r -> era where
	LedgerEra BabbageEra = Ledger.Babbage
	LedgerEra ConwayEra = Ledger.Conway

[Jimbo4350]

#604 (comment)