New `pop test` subcommand to simplify Rust e2e testing on Substrate based chains

[tsenovilla]

Disclaimer: Just a preliminary sketch of my ideas, just putting down what comes to mind so there's too much room for improvement. Any feedback's more than welcome.

So was thinking that we can power up pop test by including a fully working, Rust based, e2e live framework as a new subcommand (haven't thought of a name yet).

Right now the most used approach in the ecosystem would be something like:

• Forking live chains with chopsticks / running fresh chains with Zombienet.
• Interact with them, mostly using Polkadot.js. Getting ready to do some stuff like asking the nodes for a block, computing sovereign accounts, or checking basic events usually involves creating a whole setup of utilities just before being able to write a single test, eg, we had to write all this code for LAOS.

My idea will be to offer something like the following to pop users:

1. They start writing their tests directly in Rust, let's say under the folder ./e2e. Now imagine they need to, dunno, ask the balance of an account on AH and check it's correctly updated. So they write something like:

let balanceA =  statemint::system::account(whoever).free;
// More stuff
let balanceB = statemint::system::account(whoever).free;

And then imagine they need to get a finalized block from their chain:

let lastBlock = my_chain::getFinalizedBlock();

But they DON'T need to define anything of this, just trust us for the moment.

A small note here, the 2 examples above are a bit different:

• The first one is a query directly provided by the runtime, so such calls would be dynamically computed depending on the runtime (what's up pop call?).
• The second one is typically a RPC call, so here we enter in something that we can call "functions provided by POP". Those would be basic utility which can be provide to all chains, common for everyone. Here we can include sovereign account computations, relevant RPC calls wrapped, or whatever we can think of. They would be listed somewhere in the POP docs, so everyone would be aware of them.

2. The user just runs pop test <new_subcommand> --rpc-urls <blablabla> --test_dir e2e. Pop would create all the e2e scaffolding by:

• Connecting to the RPCs and downloading the relevant metadata.
• Then it can create a Rust module called after each chain specName (that's why I used statemint above) containing all the relevant functions (both the dynamically computed ones and the "functions provided by POP") and structs. Thinking that --rpc-urls can contain custom names in case they wanna use different names for those modules.
• Pop gathers all these modules inside a new Rust module inside the tests folder -> so those modules are already defined and the test crate can be compiled now.
• Pop builds the test crate and run tests normally, all the defined functions will point to the right RPC URL, so we can send calls to every node on demand as we do with Polkadot.js API's.

I'm also thinking that we can have a --commit-setup flag. If it's specified all the setup will be committed to the user codebase so they can play with everything as they want to. Otherwise it'll be rolled back and the test will be running in a temp dir containing the setup and the tests, created and deleted by pop, so the user codebase isn't polluted. This crate I wrote when working on #524 might be super helpful for this in case you think it makes sense to have this flag (please gimme feedback here).

This can be used with Zombienet and chopsticks of course, but also (and preferably) with the upcoming pop fork command <- This will make pop a super hero in testing against forked live chains.