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~~

• [x] ~~#2~~
• [x] ~~#3~~
• [x] ~~#4~~
• [x] ~~#5~~
• [x] ~~#6~~
• [x] ~~#7~~
• [x] ~~#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

• [ ] #23 : Responsible for additional capabilities - not specific to our problem space (./crates/support)
• [x] #24 : Responsible for creating the configuration and updating it (./crates/configuration)
• [ ] #25 : Responsible for the interaction between different providers (./crates/providers)
• [ ] #26: Responsible for bringing the state of the running network to the expected configuration and managing it in real-time (./crates/orchestrator)
• [ ] #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.

• [x] #9
• [x] #10
• [x] #11

Refactor CLI and ensure backwards compatibility

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

• [ ] #12
• [ ] #13
• [ ] #14