Stateful property-tests for the error/failure paths in PoX-4

[BowTiedRadone]

This PR implements a strategy to test malicious user interactions with the PoX-4 contract, covering specific scenarios to ensure correct handling.

Structure
A new file with unhappy path scenarios has been added. See contrib/boot-contracts-stateful-prop-tests/tests/pox-4/err_Commands.ts, where each scenario has a generator simulating malicious behavior and specifying the expected PoX-4 error code.

The rest of the files in this PR are infrastructure.

---

Statistics
To facilitate the review of post-execution test-run statistics, tree logging has been added:

├─ AllowContractCallerCommand: 35
├─ DelegateStackExtendCommand: 3
├─ DelegateStackIncreaseCommand: 4
│   ├─ Err_Stacking_Insufficient_Funds: 5
│   ├─ Err_Stacking_Invalid_Amount: 3
│   ├─ Err_Stacking_Not_Delegated: 14
│   └─ Err_Stacking_Permission_Denied: 1
├─ DelegateStackStxCommand: 3
│   ├─ Err_Delegation_Too_Much_Locked: 2
│   └─ Err_Stacking_Permission_Denied_2: 2
├─ DelegateStxCommand: 22
│   └─ Err_Stacking_Already_Delegated: 16
├─ DisallowContractCallerCommand: 6
│   └─ Err: 39
├─ GetStackingMinimumCommand: 57
├─ GetStxAccountCommand: 30
├─ RevokeDelegateStxCommand: 14
│   └─ Err_Delegation_Already_Revoked: 26
├─ StackAggregationCommitAuthCommand: 1
│   ├─ Err_Stacking_No_Such_Principal_1: 12
│   └─ Err_Stacking_No_Such_Principal_2: 28
├─ StackAggregationCommitIndexedAuthCommand: 1
│   ├─ Err_Stacking_No_Such_Principal_1: 7
│   ├─ Err_Stacking_No_Such_Principal_2: 22
│   └─ Err_Stacking_Threshold_Not_Met: 1
├─ StackAggregationCommitIndexedSigCommand: 0
│   ├─ Err_Stacking_No_Such_Principal_1: 12
│   ├─ Err_Stacking_No_Such_Principal_2: 29
│   └─ Err_Stacking_Threshold_Not_Met: 1
├─ StackAggregationCommitSigCommand: 1
│   ├─ Err_Stacking_No_Such_Principal_1: 13
│   ├─ Err_Stacking_No_Such_Principal_2: 34
│   └─ Err_Stacking_Threshold_Not_Met: 2
├─ StackAggregationIncreaseCommand: 2
│   └─ Err_Stacking_No_Such_Principal: 7
├─ StackExtendAuthCommand: 6
│   ├─ Err_Stacking_Invalid_Lock_Period: 7
│   └─ Err_Stacking_Is_Delegated_1: 1
├─ StackExtendSigCommand: 2
│   ├─ Err_Stack_Extend_Not_Locked: 2
│   └─ Err_Stacking_Invalid_Lock_Period: 5
├─ StackIncreaseAuthCommand: 11
│   ├─ Err_Stacking_Insufficient_Funds: 24
│   ├─ Err_Stacking_Invalid_Amount: 10
│   └─ Err_Stacking_Is_Delegated: 3
├─ StackIncreaseSigCommand: 12
│   ├─ Err_Stacking_Insufficient_Funds: 13
│   ├─ Err_Stacking_Invalid_Amount: 13
│   └─ Err_Stacking_Is_Delegated: 3
├─ StackStxAuthCommand: 1
│   ├─ Err_Stacking_Already_Stacked_1: 21
│   └─ Err_Stacking_Already_Stacked_2: 9
└─ StackStxSigCommand: 5
    ├─ Err_Stacking_Already_Stacked_1: 14
    └─ Err_Stacking_Already_Stacked_2: 14

[moodmosaic]

Thank you @BowTiedRadone 🙌

[friedger]

That is a lot of new code.
The comments on the commands do not describe the functions.

[moodmosaic]

@friedger, yes, those classes are templates. From one template, multiple unhappy paths can be derived. It's a good point that the comments should be updated.

---

For your information, in sBTC invariant testing, the boilerplate/setup will be significantly reduced. We now have a new syntax for bundling the randomly-generated inputs with the commands. For example, consider this Clarity code snippet from a demo:

(define-data-var counter uint u0)

(define-constant ERR_COUNTER_MUST_BE_POSITIVE (err u401))

(define-public (decrement)
  (let ((current-counter (var-get counter)))
    (asserts! (> current-counter u0) ERR_COUNTER_MUST_BE_POSITIVE)
    (ok (var-set counter (- current-counter u1)))
  )
)

The invariant in Clarinet/TypeScript is defined as:

import { tx } from "@hirosystems/clarinet-sdk";
import { Cl } from "@stacks/transactions";
import fc from "fast-check";

const accounts = simnet.getAccounts();

export const CounterDecrement = fc
  .record({
    sender: fc.constantFrom(...accounts.values()),
  })
  .map((r) => ({
    check: (model: Readonly<Model>) => {
      return model.counter > 0;
    },
    run: (model: Model, real: Real) => {
      const block = real.simnet.mineBlock([tx.callPublicFn("counter", "decrement", [], r.sender)]);
      expect(block[0].result).toBeOk(Cl.bool(true));
      model.counter = model.counter - 1;
    },
    toString: () => `decrement`,
  }));

In the current setup, this logic is split into two places, with one part being a class (constructor, readonly fields, etc.). In sBTC, everything will be declared in one place. /cc @hugocaillard @setzeus

[hugocaillard]

Some refactor suggestions.

Considering the size of the code base, I think you would greatly benefit from using a code formatter and a linter (prob in a different PR)

[hugocaillard]

LGTM!
Impressive work

[friedger]

LGTM