Kwxm/costing/restore old cost model param names

[kwxm]

The changes in #5857 caused some of the cost model parameter names (for equalsByteString and equalsString) to change, which introduced a conflict with some of the names in the Alonzo genesis file. The parameter names changed because one of the costing function types had a linear function hard coded into it and I replaced it with something where you could have a more general type. I've now added the more specific type back: it's redundant but it has the right names. See this Note for more information.

A few other points:

• The ledger code is already adjusting some of the cost model parameter names here and that code could easily be extended to deal with this problem as well.
• What I've done here is a stopgap to restore the old behaviour. The parameter names are automatically derived from constructor names using Aeson's FromJSON/ToJsonmethods. A better way to solve our problem might be to write custom FromJSON/ToJSON instances that convert the restricted linear_on_diagonal tag to the more general ConstantOffDiagonal constructor, so that we'd have a sort of syntactic sugar that could convert the JSON encoding of our old types into the internal version of our new types. That might take some time though, so I've gone for a quicker fix here.
• We probably do want to use the new tags and types exclusively in Conway. I think that should be OK since my understanding is that there will be a new genesis file for the post-Conway era and we can use the new parameter names in that. This will require some changes in plutus-ledger-api and I think it'll also depend on the work that's currently in progress on allowing configurable cost models (see here for example, although there's more work to be done).

[effectfully]

Sorry for the late review. LGTM.

It sucks that we can't change the names easily. Also relying on aeson is generally horrible, I do believe we should bite the bullet and have everything written out explicitly, even though it's a lot of boilerplate.

Could you please create a GitHub issue with the appropriate details from your original comment to make sure we don't forget about this problem?

[kwxm]

Could you please create a GitHub issue with the appropriate details from your original comment to make sure we don't forget about this problem?

Yes, I was planning to do that (so thanks for the reminder). I think we should also keep a careful record of the history, so we can see how to relate old parameter names to new ones.