Introduce stacked filtering

[gavofyork]

This introduces a mutable IsCallable and thus fixes some issues making utility and proxy dangerous to use together.

Also introduces as_limited_sub which is exactly like as_sub except that the sub-calls are restricted by the same filter that applies to the caller (as before). This might find use if you want to create an account with several stash or governance sub-accounts, and a single proxy for it that can only be used for these functions (rather than needing multiple proxies, one for each sub account).

This also repots Utility pallet's multisig functionality into its own pallet, Multisig, thereby making Utility stateless.

In summary:

• proxy[only_utility](batch(transfer(...))) now results in error.
• proxy[only_utility](multisig(transfer(...))) still succeeds.
• proxy[only_utility](as_sub(transfer(...))) still succeeds.
• proxy[only_utility](as_limited_sub(transfer(...))) results in error.
• proxy(batch(add_proxy(<more_permissive>))) now results in error.

TODO:

• Test for proxying
• Tests fot impl_filter_stack!
• Extract IsCallable & the call stack functionality into something re-usable
• Migration Utility/multisig -> Multisig

NOTE: This will be retired once we have in-origin filtering, which should be ready in the NTD future.

Polkadot companion: paritytech/polkadot#1212

[xlc]

This seems added a lot more context that are required to know in order to code securely. I hope they are documented throughly.

[gavofyork]

Let me know if there's something specific that needs explaining.

[xlc]

When do we need to call FilterStackGuard and ClearFilterGuard?
Seems like FilterStackGuard is needed before granting additional permission and ClearFilterGuard is needed before dispatch calls with different origin?

This seems like a way to prevent reentrancy attack, but it is not easy to wrap my head around with all the indirections (proxy, multisign, sub account call, batch call, governance call?, and calls from contracts).

[gavofyork]

There's no clear-cut way of knowing when to call them as it depends entirely on the semantics of your dispatcher.

Basically, the FilterStack paradigm allows you to alter a static Filter by pushing one or more filters onto it and temporarily clearing it. The real runtime filter stacks are implemented by a macro that supplements this model with a base-filter which always gets applied.

The reason for this is:

• Base filter is used to disable signed calls to certain modules throughout the codebase.
• The push/pop stack allows proxy module to restrict inner dispatches; we can't just filter the immediate inner Call because it could be a re-caller such as batch, into which the restrictions should persist.
• The temporary clearing is needed to allow for inner calls to multisig or proxy which, as newly authorised dispatch origins, need not inherit the restrictions of their caller (though we want to ensure that when they return to the caller context, the restrictions are back in place).
• as_sub is an example where it's unclear whether any call restrictions should persist. As is documented, both are quie reasonable and have their use-cases. For this, we have split it into two calls as_sub (restrictions do not persist into the inner) and as_limited_sub (restrictions do persist).