Zombienet testing for validator disabling

[tdimitrov]

The tests should validate that validator disabling and the disabling strategy behaves correctly.

Base test cases to cover:

• General case: disable less than THRESHOLD validators. Verify the network behaves correctly.
• Too many offenders (is it possible with zombienet?): Generate a lot of minor offenses for THRESHOLD+1 validators. Ensure that no more than THRESHOLD number of validators are disabled and the network behaves correctly.
• Re-enabling: Less than THRESHOLD number of validators has committed major offences (e.g. suggest garbage candidate). The rest of the validators keep on committing minor offences. Ensure that the network behaves correctly and that the big offenders are always disabled.

Note: THRESHOLD is an implementation parameter representing max number of validators we can have disabled at each point in time.

Part of https://github.com/paritytech/polkadot-sdk/issues/784

[ordian]

1841 adds a basic zombienet test which only checks for the log line about disabled state. This is not exactly what we want, which is to test the effects of disabling:

• once a (malus) validator initiated a dispute that concluded against them, it should no longer be able to initiate disputes and their backing statements should be ignored

this is a bit tricky to test with the current zombienet v1 as the .zndsl framework is quite limited and not a (turing-complete) language. We will need an ability to assert that some metrics hasn't increased after some (unknown at compile time) point. I believe this will be addressed with zombienet v2 (cc @pepoviola)

[pepoviola]

1841 adds a basic zombienet test which only checks for the log line about disabled state. This is not exactly what we want, which is to test the effects of disabling:

• once a (malus) validator initiated a dispute that concluded against them, it should no longer be able to initiate disputes and their backing statements should be ignored

this is a bit tricky to test with the current zombienet v1 as the .zndsl framework is quite limited and not a (turing-complete) language. We will need an ability to assert that some metrics hasn't increased after some (unknown at compile time) point. I believe this will be addressed with zombienet v2 (cc @pepoviola)

Hey @ordian, sorry about the delay. We expect to have the new version ready for start moving some workload by the end of next week. We can start exploring this case with the native provider now and move to k8s in the near future. Thx!