Remove code repetition in Conway era CDDL

[iccicci]

Description

protocol_version is defined as a group and always referred nested (alone) inside an array.

I introduced protocol_version_ with the purpose to not change protocol_version definition: I don't know if there are some reasons to keep the definitions unchanged between CDDL versions; if that's not the case and I was too scrupulous, we could simplify this PR removing protocol_version_ and changing protocol_version definition.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[teodanciu]

I'm not convinced of the benefits of this change.
protocol_version_ name is a little inexpressive, in my opinion, for a singleton list of protocol_version (unless there is some convention I'm not aware of). So whenever it's encountered, it has to be looked up to understand what it is.
Maybe we could find a better name for it?

On the other hand, defining protocol_version itself as a singleton list doesn't seem right either - whereas it would reduce duplication, it can be misleading when reading the types that are referencing it.

But maybe I'm missing something - is this duplication creating problems in some ways that are not obvious? Just curious

[iccicci]

On the other hand, defining protocol_version itself as a singleton list

From this sentence it seems there are no reasons to keep unchanged definitions between eras; if I am correct, I would prefer this option both for shortness and for clarity.

it can be misleading when reading the types that are referencing it.

I can't get the point here. Wouldn't it be just as any other defined type? Could you please elaborate? Thank you

protocol_version_ name is a little inexpressive...
Maybe we could find a better name for it?

For sure! Maybe protocol_version_obj or protocol_sem_ver or any other suggestion will be appreciated.
Anyway, until is possible to change the current definition of protocol_version, I would focus on that option.

is this duplication creating problems in some ways that are not obvious?

In my specific case, I spent more or less one hour trying to understand the reason for this repetition.. and I ended up opening this PR.
In cardano-js-sdk we started a process to make the SDK as compliant as possible to the Ledger: the presence of this repetition reflects in forcing us to replicate the repetition in SDK or to tolerate a discrepancy (if we want to avid the code repetition).

Thank you

[lehins]

I don't know if there are some reasons to keep the definitions unchanged between CDDL versions; if that's not the case and I was too scrupulous, we could simplify this PR removing protocol_version_ and changing protocol_version definition.

I am all in favor of this suggestion.

[iccicci]

is this duplication creating problems in some ways that are not obvious?

Please let me elaborate my thought about this question.

This document is not an end in itself, it is the refernce for thousands of other projects. For this reason, in my opinion, it should be kept as clear and minimal as possible.

If I may allow one more suggestion, I would move the big comment it has in its middle to a README.md file changing the big comment with a short comment with just a link referencing the section of the chosen README.

[teodanciu]

Thank you for the explanation @iccicci, I concede to the non-indirection approach that you and Alexey suggested, as my concern seems indeed unfounded.

[teodanciu]

Rebased against master

[teodanciu]

Looks good to me