[Improvement] Enshrine account default validation feature

[howydev]

Most SCA implementations today have a “default owner” or “default validator” feature which is a validator that can be used on all/most user operations or transactions to the account. We should consider enshrining this and have all ERC6900 accounts implement a default validator feature.

1. Accounts without a default validator require a lot of storage operations on creation to initialize validators on all native functions (we do ~10-20 SSTOREs for ERC6900 Ref Impl), whereas with a default validator feature, this could drop down to a single SSTORE
2. For a plugin dev, most of the time, the validator they want to use on a plugin execution function is “whoever controls the account” i.e. the default validator. To accomplish this today, they have to be familiar with the commonly used ownership plugins and the shape of those validation functions. Enshrining default validation in the spec and allowing plugin manifests to specify that would greatly reduce the barrier for plugin devs

Possible changes to the spec to explore:

1. Accounts MUST implement a default validator plugin
2. Accounts MUST allow for configurations in which default validation would no longer be valid for certain execution paths
3. When installing executions on the account, plugins MAY request to use the accounts default validator on the newly installed execution function

[jaypaik]

This seems related to #16.

[huaweigu]

This seems related to #16.

Previously, we focused on enhancing the validation process. We updated the validation logic to accurately identify and handle calls to both native functions and plugin functions, directed by a feature flag within the account's storage. Plugins that rely on native validation logic for their installation might include specific dependencies, such as

FunctionReference(mscaAddr, uint8(SingleOwnerMSCA.FunctionId.NATIVE_RUNTIME_VALIDATION_OWNER_OR_SELF)). 

However, this approach essentially serves as a temporary solution given the current status of specifications. We're exploring methods to define clear interfaces or a core validation layer applicable to both account-native validations and plugin validations. Additionally, we are exploring the potential for incorporating hooks to enhance flexibility.

I can probably look into this as well since https://github.com/erc6900/resources/issues/16 is already on our radar.

[fangting-alchemy]

Having a default validation would enhance the flexibility of a modular account quite a bit. I think it is a great a idea to include it.

The question comes down should accounts have a pool of default validators or a singe validator given that multiple validators are supported on a per selector level.

Or better, to simplify effort for both plugin devs and client devs, accounts can have a pool of default validators and/or a singe custom/specific validator in the event when a plugin execution function requires a custom validator.

A validation pool seems provide more options for plugins. However, the introduced complexity conceptually and technically is not worth it. Especially since the optionality can be achieved with the current existing validation scheme.