feat: add tessera, the gno.land E2E testing harness

[zivkovicmilos]

Description

Closes #2530

⚠️ This PR is a heavy WIP, and completely unstable. Please wait for the codebase to be stabilized before attempting to use.

The PR introduces tessera, an E2E testing harness for gno.land, without the in-memory node bullshit.
It is built on the concept of "recipes" and "scenarios" that can be stacked on top of a fully customizable node cluster.

From the README:

Recipes are the backbone of the tessera testing harness. Recipes can mix-and-match existing scenarios to produce a
flow that needs to be verified, and working under specific conditions.

The tool adopts the following terminology:

• Cluster - a live (branch-version) node set (network). Every aspect of each node is configurable.
• Scenario - a test case (user story) that can be executed against a cluster. Think of them as legos for Recipes
• Assertion - a validation that should be performed on the cluster (after / before a scenario). They are bundled with
  Scenarios.
• Invariant - a validation that verifies an invariant condition of the cluster, independent of specific scenarios.
• Recipe - a declarative specification of a cluster topology and a sequence of scenarios to execute against it.

Important points:

• The setup flow follows real-life node / network setups. It builds images from the branch Tessera is in, and spins up nodes using the built images.
• The harness user simply needs to define a new recipe (in yaml), using existing scenarios (or writing new ones in Go), and let tessera handle the rest. We will document all of this in tessera/docs.
• tessera generates artifacts in the form of logs, which can be saved by tools like Dagger and served to end-developers to understand what went wrong with the cluster test. The idea is to combine tessera with something like Dagger CI to create canary deployment workflows that we can trust.

Example recipe:

name: multi-node-boot
description: Tests a cluster with 4 peers to verify basic network boot

cluster:
  nodes:
    - id: "*"
      config:
        consensus.timeout_commit: 100
        consensus.create_empty_blocks: true
        consensus.create_empty_blocks_interval: 0
        p2p.persistent_peers: [ "{{peer1.p2p.laddr}}", "{{peer2.p2p.laddr}}", "{{peer3.p2p.laddr}}", "{{peer4.p2p.laddr}}" ]

    - id: peer1
      role: validator

    - id: peer2
      role: validator

    - id: peer3
      role: validator

    - id: peer4
      role: validator

scenarios:
  # Wait for the initial network formation
  - name: wait_for_peers
    params:
      peerCount: 3
      peersInclude: [ "{{peer1.p2p.laddr}}", "{{peer2.p2p.laddr}}", "{{peer3.p2p.laddr}}", "{{peer4.p2p.laddr}}" ]
      timeout: 30s

  # Wait for some blocks to be produced
  - name: wait_for_height
    params:
      height: 5
      timeout: 30s

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)
• Determine if infra needs to be updated before merging

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

No automated checks match this pull request.

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

Determine if infra needs to be updated before merging

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 Or
        ├── 🟢 A changed file matches this pattern: Dockerfile (filename: contribs/tessera/pkg/cluster/docker/Dockerfile)
        ├── 🔴 A changed file matches this pattern: ^misc/deployments
        ├── 🔴 A changed file matches this pattern: ^misc/docker-
        ├── 🔴 A changed file matches this pattern: ^.github/workflows/releaser.*\.yml$
        └── 🔴 A changed file matches this pattern: ^.github/workflows/portal-loop\.yml$

Can be checked by

• team devops

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

📢 Thoughts on this report? Let us know!

[n0izn0iz]

Did you look into deterministic simulation testing? If yes why not attempt that?

(It's already awesome to have proper e2e testing btw <3)