Custom Additional Per-Task Validations

[sebastianst]

We currently lack some validations with the new task framework that were happening with the old framework. I think we need a way to add back per-task custom validations, especially those which we now exclude as expected errors.

The new scops task framework works with template Solidity scripts that also define generic validations that run for all tasks. But then it is expected that the on-chain StandardValidator returns some errors. E.g. in the case of the Sepolia Unichain Isthmus prestate upgrade (U15), we define the following list of expected erros: https://github.com/ethereum-optimism/superchain-ops/blob/f42ea91b0951acc67c4453a09b25412789eb2754/src/improvements/tasks/sep/012-opcm-update-prestate-v300-uni/config.toml#L10-L17

But what's now missing are assertions what these values should be instead. E.g. the first expected error is PROXYA-10: ProxyAdmin owner is not set to L1 PAO multisig - expected. But we don't have any assertions who should be the right PAO instead. Worst case, this can lead to us ignoring wrong values because we just dismiss this check as an expected error.

I see two solutions

1. Add optional validation Solidity scripts to tasks, that would probably inherit the template so all fields and functions are available as they are in the template. So there would be a solidity script for a task like in the old framework, but only optionally. This option solves the problem very generically.
2. Improve the StandardValidator errors to include contextual information, so that the asserted errors also assert on the alternative field values instead. E.g. in the above example, the error code PROXYA-10 could be extended to include the actually found owner in parenthesis, like PROXYA-10(0x<actual-address>). This would probably work for most errors and ensure when we expect errors, we also implicitly assert on the alternative value.

[blmalone]

@maurelian as I know you're looking into StandardValidator improvements.

[maurelian]

Thanks yes, my plan here is that, for these checks which require more flexibility, I would allow for the expected value to be provided as input to the validate() call, and then do option 2:

E.g. in the above example, the error code PROXYA-10 could be extended to include the actually found owner in parenthesis, like PROXYA-10(0x). This would probably work for most errors and ensure when we expect errors, we also implicitly assert on the alternative value.