Fix JSON parsing for CostModels

[lehins]

Description

JSON parsing for CostModel is incorrect today. The problem lies in the fact that starting with Conway era number of cost model can vary, while number of parameters in any genesis file must stay the same, since that was the number of parameters with which era was initiated with.

Confirmation of the problem and the fix is in a separate PR due to the amount of changes it required: #5243

This PR:

• fixes the parsing where addition of new cost model parameters in a newer version of plutus results in a failure, unless new parameters are added to the genesis file, which would be a wrong thing to do.
• Fixes the total number of parameters with which conway era has started with. This was a not really a problem, since parsing for cost model parameters in Conway did not enforce the initial number
• Start enforcing the initial number of parameters in the Conway Genesis

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.

[aniketd]

Both the test failures pertain to the change in the parameter name counts from 231 to 251.

Looks good to me otherwise 👍

[teodanciu]

@aniketd Would you mind reviewing my test fix, if you're still around?

[teodanciu]

Interesting that the JSON deserialization of CostModels has so much more complexity compared to the CBOR one (untouched by this change), with a wider definition of what "lenient" means. I suppose because the JSON in the genesis file) is more error prone ? Whereas for CBOR we know what we serialize.

Anyway, looks good to me.

[aniketd]

@teodanciu LGTM! 🙌

[lehins]

I suppose because the JSON in the genesis file) is more error prone ?

No, it is because JSON for CostModel in Genesis file must be stable (i.e. Genesis files never change on mainnet), while JSON in LedgerState and CBOR in transaction are more versatile. Hence is the distinction between lenient and strict.