Ensure that CC member can serve a full `CommitteeMaxTermLength`

[lehins]

trafficstars

Current check during ratification happens on the one epoch before last due to the pulser delay: https://github.com/IntersectMBO/cardano-ledger/blob/8fd7ab6ca9bcf9cdb1fa6f4059f84585a084efa5/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Ratify.hs#L312C12-L312C30

The affect of this is that any newly elected committee would never be able to serve the full CommitteeMaxTermLength protocol parameter, it would always be at most one less than that.

We need to fix this before cardano-node-10.0 release, i.e. before the Chang+1

CC @WhatisRT This will also need to be fixed in the formal-ledger-spec

[WhatisRT]

I don't think anything actually needs to change here. Assume CommitteeMaxTermLength = 1, and we're at epoch e. Then, if you make a proposal with term e+2 and it gets voted on immediately the ratification will check it with the maximum term of (e+1)+1, so it can be enacted. Then, during epoch e+1 that CC member can register a hot credential and vote. During the next ratification, the epoch that's passed in will be e+2, so the expiration check for that CC member will be e+2 <= e+2 which is true, so the vote counts. In the following epoch the check will be false, so the CC member had exactly one epoch which is as expected.

[lehins]

After doing the audit, @WhatisRT and I have convinced our selves that there is indeed no issue here. Because delaying by one epoch happens consistently CC members do actually serve the full term. That being said we do need to have an imp test that checks it is indeed correctly implemented, except not through expiry field comparison, but through checking that CC member's votes count throughout the whole period that the CC member is expected to be active. Setting CC expiry to maxTermLength is a necessary for this test.