[DRAFT] feat: [v0.8-develop, experimental] stateful composable validation

[adamegyed]

Motivation

We've done a lot of research into composable stateless validation, and why it's useful. It is also possible to do composable stateful validation, this branch explores one potential way to pursue this

Solution

In a very basic sense, one way to enable validation composition is to allow validations to tell the account to send out another call to validateUserOp to some other validation plugin, and use that as part of the validity calculation.

However, validation functions currently assume:

• The incoming user op is actually from the entry point
• The EntryPoint handles nonce & user op hash uniqueness
• If validated, the account will actually perform that user op.

If we implemented "validation forwarding" in a naive way where a validation can call back into the account to perform another validation, some of these assumptions may be hard to enforce - what if the calling validation modified the user op or the hash?

So, rather than allowing a callback, what if a validation function was allowed to return a list of additional validation functions that must be run, and coalesce the result of all of these "chained" validation functions? Each validation function within this could then further chain calls, allowing arbitrary composition of validation functions.

Essentially, this allows a validation to return "conditional validity" - aka "validate this user op only if you ALSO validate it using these other validation function(s)".

This PR implements this "validation chaining" mechanism, and has a demonstration using an ECDSA validation plugin and a composable multisig plugin. For simplicity, the multisig plugin requires all owners to sign, instead of specifying a threshold, but one could be implemented with a threshold, too.

TODOs

This PR is a proof-of-concept, and leaves out some necessary details:

• It only implements composable user op validation, not runtime or signature validation
• It does not yet enforce validation uniqueness - hypothetically, a multisig could return the same validation multiple times, and if that validation had a gas spend limit, it would be able to grief it by multiplying the usage. This can be prevented by enforcing that each validation is fired at most one time per user op hash, and we can track this in either memory or transient storage.
• This uses a lazy definition of "install state" for a validation, relying only on state within the plugin. We may want to move some of this into the account, if we actually pursue something like this.

[adamegyed]

Closing for now because we're likely not going to pursue this as a path. We can re-open if we decide that state-changing validation functions / pre-validation hooks in "inner" validations are important.