[draft] feat: [v0.8-develop] Only allow installing direct call validation via manifest 3/N Option 1

[adamegyed]

Motivation

Since the introduction of installValidation as a fully user-controlled install function, there have been two different ways to install validation funcitons from plugins:

• The caller can specify the validation function, flags, and any pre-validation / permission hooks via installValidation
• The caller can install a plugin that declares a validation function in its manifest. In this setup, there is no opportunity to apply pre-validation or permission hooks.

In practice, most uses of validation functions in manifests were for allowing "direct call validation", aka recreating the old executeFromPlugin workflow.

Solution

This PR explores one possible solution to removing the redundancy, by making the only possible validation function to install via a manifest the direct call validation.

Future work

If we choose this path, we will need to add a way to specify pre-validation + permission hooks for the direct call validation functions installed via the manifest.

[howydev]

i like the check as a safety mechanism, because installation of non plugin contracts can be dangerous (installing ERC20 tokens/ERC20.transfer.selector as an execution selector to transfer contract tokens out)

Are you thinking of moving it to the SDK to reduce pollution in the tx traces? That's something I'll support. I think we can say with high confidence that most accounts are used with their paired SDKs today, and will be the case in the future, so safety checks in the SDK are equally effective as on chain.

[adamegyed]

I was thinking of adding a view function to IModule that would do something similar to the ERC-165 check, basically just validating that the provided address does report itself to be a module of the appropriate type. But for now, I think it's ok to leave it as the 165 check.

[adamegyed]

Closing this to prioritize #104