Court: Polish main court contract functionality

[facuspagnuolo]

Fixes #83 and #16

Lots of polishing stuff, inline documentation and bunch of new tests happening on this PR, important pieces to take a look carefully are:

• ⚠️ Ensure first term is in the future (53ff9e3#diff-4bb317b489994cf6f4c4b7ed11c18590R235)
• ⚠️ Ensure term is not zero when creating disputes (79abd26#diff-4bb317b489994cf6f4c4b7ed11c18590R297)
• ⚠️ Ensure appealer cannot confirm an appeal (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R456)
• ⚠️ Use start term id of the final round to fetch the total active balance of the jurors' registry when computing the jurors number (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R1294)
• Unify appeal struct (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R172-R177)
• Handle Pre-Draft and Executed dispute states when querying an adjudication round state (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R1362-R1371)
• Add round getter (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R760)
• Add appeal getter (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R796)
• Update settledJurors even for the last batch to ensure consistency (2e3cbbd#diff-4bb317b489994cf6f4c4b7ed11c18590R1008)
• New thousands percentage lib (0cb4d62?file-filters%5B%5D=.sol#diff-7c2369ae5667d560b954f85000fff662R6-R22)

[izqui]

Looking really good so far, some minor comments

[izqui]

Some minor comments that I forgot to submit

Edit: moving them to #104

[bingen]

Still reviewing, but here you have another batch.
Before I forget, I realized there are some lint errors. I will push a small PR to add linter to CI, ok?

[bingen]

I wouldn't call this Ensured, as it can be misunderstood as if we somehow know that we have already called ensureTerm and it's up to date.

[facuspagnuolo]

Not sure I follow the scenario you are describing. IMO this is what termId actually means, it's the last ensured term since it may be outdated.

[bingen]

Ok, again, proceed as you want, it's just a name, but to make my point clear: if termId means "the last ensured term", I don't see the need for adding Ensured as it would be just confusing, like there are 2 different concepts, termId and ensuredTermId.
But I don't think termId is "ensured" at all, as we don't know if all needed term transitions have taken place.
Anyway, to me this is just and old plain getter:

    function getLastEnsuredTermId() external view returns (uint64) {
        return termId;
    }

And it's a common practice to name getters as get + variable name. So if you really want to call this with that (IMO) unnecessary long name instead of the classic getTermId, I would then rename the variable to lastEnsuredTermId.

[Suggestion for our style guide, section naming conventions: plain getters are called get + variable name]

[izqui]

This is definitely a bit of bikeshedding at this point, but what about getLastTransitionedTermId?

[bingen]

I agree it's bikeshedding. Actually I don't think we even need this function at all, as we could have kept termId public and use the automatically generated getter.
[Another thing to discuss for our style guide: do we use public state variables and auto-generated getters? Or do we declare them all internal and explicitly write getters?]

[facuspagnuolo]

I like getLastTransitionedTermId and also agree about the getters pattern, I think the whole problem comes as a consequence of the state variable being called simply termId which is not always up-to-date. What about renaming the variable to lastTransitionedTermId as well?

[izqui]

Outstanding work on this @facuspagnuolo!

Some minor comments, but good to go on my end to merge 🔥

[facuspagnuolo]

@izqui I already addressed all your comments. Please take a look at the related changes, I'd recommend reviewing them by commit.

⚠️ I improved and added some other appeal tests in e2cac0b, and also noted that we may be missing the final round reduction here. LMKYT

[izqui]

LGTM

[izqui]

Good catch. I don't think we should have it here though, but it should definitely be in settleReward when assigning fees for coherent jurors in the final round

aragon-court/contracts/Court.sol

Line 591 in e2cac0b

accounting.assign(config.feeToken, _juror, jurorFee);

And we should definitely have a test for it. Maybe we should work on it on a specific test file for accounting?

[bingen]

Hm, I don't get it. round.jurorFees already has the discount applied, right?

[facuspagnuolo]

True, I was confused. The problem was that we are not testing it 😂