fix: ci integration tests chopsticks

[Ad96el]

fixes #3252

This pull request introduces several enhancements and updates to the integration tests for the Chopsticks project. The changes include updates to environment variables, workflow configurations, dependencies, and the addition of new helper functions and documentation. Below are the most important changes grouped by theme:

Workflow and Environment Configuration:

• Updated environment variables in .github/workflows/check-code.yml to include block numbers and WASM overrides for different networks. Added a setup for Cargo cache to improve build efficiency. [1] [2] [3]
• Modified the .env-example file to include new mandatory and optional environment variables for the tests.

Documentation:

• Added a comprehensive README.md for the Chopsticks integration tests, detailing setup instructions, environment variables, running tests, code style, adding new test cases, debugging, and recommended VS Code extensions.

CLI and Command Enhancements:

• Introduced a new CLI in src/cli.ts to manage Chopsticks instances with commands for spinning up networks, scheduling transactions, and showing state transitions.
• Added command implementations for creating test networks, scheduling transactions, and showing state transitions in src/command/index.ts, src/command/network.ts, src/command/scheduleTx.ts, and src/command/stateTransition.ts. [1] [2] [3] [4]

[rflechtner]

Obviously this is too big a PR for me to fully review, but I scanned it for strange uses of the polkadot api and of async JS, of which I flagged a few. But generally looks good.

[rflechtner]

we don't have access to the actual codec types for this pallet unless you import them from @kiltprotocol/augment-api, but many common types are available from @polkadot/types/interfaces. The Option Codec is one another basic codec type, and is available from @polkadot/types. Typescript has generics syntax just like rust, and types (like an Option Codec type) can be generic.

[rflechtner]

I've made a more useful example of specifying the query return type earlier in this second review

[rflechtner]

the syntax you used before was completely fine; this one is ok too though, but unusual. To summarize, these are ok:

// Returns a resolved promise containing the result of tearDownNetwork
afterEach(async () => await tearDownNetwork([receiverContext, senderContext, relayContext]))
// Returns a promise of tearDownNetwork's result directly, but is functionally identical to the above (indistinguishable for the caller)
afterEach(async () => tearDownNetwork([receiverContext, senderContext, relayContext]))
// Also returns a promise, because tearDownNetwork is async (but would be sync if tearDownNetwork were sync) - also functionally identical
afterEach(() => tearDownNetwork([receiverContext, senderContext, relayContext]))
// Same as above but with brackets
afterEach(() => {return tearDownNetwork([receiverContext, senderContext, relayContext]))}
// Also the same as earlier but with brackets
afterEach(async () => {return await tearDownNetwork([receiverContext, senderContext, relayContext]))}
// Not strictly the same - this returns a `Promise<void>` (but if tearDownNetwork did too, this would be functionally identical again)
afterEach(async () => {await tearDownNetwork([receiverContext, senderContext, relayContext]))}

Don't do this though:

// Uncaught promise - the result is not handled nor awaited. The outer function always resolves.
afterEach(async () => {tearDownNetwork([receiverContext, senderContext, relayContext]))}
// Uncaught promise - the result is not handled nor awaited. The outer function is sync and returns void immediately.
afterEach(() => {tearDownNetwork([receiverContext, senderContext, relayContext]))}
// Illegal use of await in sync function
afterEach(() => {await tearDownNetwork([receiverContext, senderContext, relayContext]))}

[Ad96el]

oh yes sorry I forgot the await there: 6e71bf1