Add property-based tests for signers-voting contract functions

[moodmosaic]

Description

Add property-based tests for signers-voting contract functions

• reward-cycle-to-burn-height
• burn-height-to-reward-cycle
• is-in-prepare-phase

This effort, initially part of #4286, is now in a separate commit and PR as it's autonomous with regards to PoX-4 property and fuzz testing. Additional property-based tests for the remaining functions of the signers-voting contract are warranted and will be addressed in separate commits/PRs.

Applicable issues

• [DO NOT MERGE] Feat/pox-4-property-testing #4286

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.40%. Comparing base (9385b42) to head (8d373fc).
Report is 1 commits behind head on next.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #4403      +/-   ##
==========================================
- Coverage   83.41%   83.40%   -0.02%     
==========================================
  Files         448      448              
  Lines      323930   323930              
==========================================
- Hits       270197   270158      -39     
- Misses      53733    53772      +39     

see 21 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9385b42...8d373fc. Read the comment docs.

[friedger]

The tests for read-only functions look good.

Maybe variation over account is not necessary, as these are read-only functions that do not use tx-sender.

For a different PR, it might be interesting to check is-in-prepare-phase with block-height in a contract call vs read-only call.

[hugocaillard]

I left a couple of suggestions.
Also, would you consider adding a formatter (such as prettier)?
Happy to help on that

[moodmosaic]

I left a couple of suggestions.

Thanks for the review!

Also, would you consider adding a formatter (such as prettier)? Happy to help on that

I always run deno ftm and go with the defaults from that. If we have some existing config for Prettier, happy to use that instead.

[hugocaillard]

Any formater is good as far as i'm concerned. But I was a bit surprised with this formatting

          pox_4_info.value.data[
            "first-burnchain-block-height"];

[moodmosaic]

Any formater is good as far as i'm concerned. But I was a bit surprised with this formatting

          pox_4_info.value.data[
            "first-burnchain-block-height"];

me too, actually. It's left from when I was adding // @ts-ignore and making sure it won't ignore more than it should. Thanks 👍After I'm done checking #4403 (comment) I'll reformat and push.

[moodmosaic]

Addressed feedback, formatted using deno fmt and force-pushed. Ready for review @hugocaillard @friedger.

[hugocaillard]

LGTM

[friedger]