Zombienet SDK [Umbrella issue]

[wirednkod]

The Vision

This issue will track the progress of the new ZombieNet SDK.

We want to create a new SDK for ZombieNet that allow users to build more complex use cases and interact with the network in a more flexible and programatic way.
The SDK will provide a set of building blocks that users can combine in order to spawn and interact (test/query/etc) with the network providing a fluent api to craft different topologies and assertions to the running network. The new SDK will support the same range of providers and configurations that can be created in the current version (v1).

We also want to continue supporting the CLI interface but should be updated to use the SDK under the hood.

The Plan

We plan to divide the work phases to. ensure we cover all the requirement and inside each phase in small tasks, covering one of the building blocks and the interaction between them.

Architecture Proposal

After [team's discussion] (#22) the following architecture was agreed to be followed as a good-initial plan:

## Prototype building blocks
Prototype each building block with a clear interface and how to interact with it

• Building block Network #2
• Building block Node #3
• Building block NodeGroup #4
• Building block Parachain #5
• Building block Collator #6
• Building block CollatorGroup #7
• Building block Assertion #8

Building blocks are replaced with the structure depicted in the image above with crates and crate components;
All issues of Prototype building blocks are closed and replaced with the ones mentioned in the next paragraph;

Crates

• Support Crate #23 : Responsible for additional capabilities - not specific to our problem space (./crates/support)
• Configuration Crate #24 : Responsible for creating the configuration and updating it (./crates/configuration)
• Provider Crate #25 : Responsible for the interaction between different providers (./crates/providers)
• Orchestrator Crate #26: Responsible for bringing the state of the running network to the expected configuration and managing it in real-time (./crates/orchestrator)
• Test Runner Crate #27: Responsible for executing tests and reporting their results (./crates/test-runner)

Integrate, test interactions and document

We want to integrate the interactions for all building blocks and document the way that they work together.

• Spawning Integration #9
• Assertion Integration #10
• Documentation #11

Refactor CLI and ensure backwards compatibility

Refactor the CLI module to use the new SDK under the hood.

• Refactor CLI #12
• Ensure that spawning from toml works #13
• Ensure that test-runner from DSL works #14