PLT-670 Add MustValidateIn to tx constraints

[berewt]

[WIP] The tests part is still missing but the validityRanges are now directly store in the Tx, not in an extra field.

Pre-submit checklist:

• Branch
  • Tests are provided (if possible)
  • Commit sequence broadly makes sense
  • Key commits have useful messages
  • Formatting, PNG optimization, etc. are updated
• PR
  • Self-reviewed the diff
  • Useful pull request description
  • Reviewer requested

[koslambrou]

For this PR, I would recreate the same tests in Spec.TxConstraints.TimeValidity, but for plutus-tx-constraints instead of plutus-ledger-constraints (keep the old one until we finally remove it).

[berewt]

Got a failure I'm unable to explain in the protocolV5Cardano test.
The transaction pass despite the validityRange, not sure if it's normal due to how we build the transaction in Tx.Constraints or not.

[berewt]

protocolV5 test keeps failing with Tx.Constraints. I wonder if it can come from the way we test in the two cases: we check that the transaction is validated within its validity range in the Tx.Constraints case, while we are checking the validity range that is stored in ScriptContext in the initial case. Unfortunately, I can't use the validator as not enough Tx.Constraints are available on main.

[sjoerdvisscher]

I'm fine with removing the V5 test, as long as we have a good negative test that shows the positive test doesn't succeed by accident.

[berewt]

It leads to the other issue with the PR at this stage: the failing test defines an unreachable range for a Tx and checks that the Tx isn't validated after some slot. Unfortunately, the transaction isn't failing either, it's just waiting for a valid slot that doesn't (and can't) come.
I think it's ok, but maybe we (I) should open an issue to investigate whether this behavior should be fixed.

[sjoerdvisscher]

Thanks, that makes a lot of sense with the explanation!