feat: add hooks for utility batch

[dmoka]

Description

In the Hydration parachain, we want to inject custom functionalities into all utility batch calls, both before and after their execution. We believe this feature could be useful for other parachains as well, where, by default, no behavior exists for custom functionalities.

Integration

This PR introduces custom hooks to the Polkadot SDK, allowing parachains to configure and extend the SDK’s behavior according to their specific requirements. The changes include:

Custom Hook Integration:

Downstream projects can now define custom hooks for specific functionality within the SDK.
These hooks can be registered during the initialization phase of the parachain.

Configuration Details:

Hooks should be defined in a configuration object and passed to the relevant utlity pallet config setup implementation.

Example usage:

impl pallet_utility::Config for Runtime {
	type RuntimeEvent = RuntimeEvent;
	type RuntimeCall = RuntimeCall;
	type PalletsOrigin = OriginCaller;
	type BatchPreHook = PushBatchExecutionTypeForUnifiedEvent;
	type BatchPostHook = PopBatchExecutionTypeForUnifiedEvent;
	type WeightInfo = weights::pallet_utility::HydraWeight<Runtime>;
}

Backward Compatibility:

These changes are fully backward compatible. Parachains that do not implement the new hooks will continue to operate as before without any modifications.

Testing Recommendations:

Projects should test their custom hooks thoroughly to ensure the expected behavior when integrated with the Polkadot SDK.
By providing these hooks, parachains can gain finer control over SDK functionalities while maintaining flexibility for future updates.

Review Notes

The BatchPreHook is invoked before every batch call (batch, batch_all, and force_batch). It is triggered immediately after ensuring the origin.

The BatchPostHook is invoked after every batch call (batch, batch_all, and force_batch). It is triggered right before collecting the weights to be returned.

To establish a default behavior, one can set the unit type in the configuration, which simply returns an Ok result, so doing nothing:

impl pallet_utility::Config for Runtime {
	type RuntimeEvent = RuntimeEvent;
	type RuntimeCall = RuntimeCall;
	type PalletsOrigin = OriginCaller;
	type BatchPreHook = ();
	type BatchPostHook = ();
	type WeightInfo = weights::pallet_utility::HydraWeight<Runtime>;
}

Checklist

• My PR includes a detailed description as outlined in the "Description" and its two subsections above.
• My PR follows the labeling requirements of this project (at minimum one label for T required)
  • External contributors: ask maintainers to put the right label on your PR.
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

You can remove the "Checklist" section once all have been checked. Thank you for your contribution!

✄ -----------------------------------------------------------------------------

[cla-bot-2021]

User @dmoka, please sign the CLA here.

[dmoka]

My labels are the following, kindly request to add them, thank you.

• T1-FRAME
• D0-easy
• R0-silent

[dmoka]

Since the unit type offers a default none behaviour, therefore no testing is required in polkadot-sdk. It has to be tested in the downstream parachains where custom logic might be added.

[bkchr]

In the Hydration parachain, we want to inject custom functionalities into all utility batch calls, both before and after their execution.

Could you give some more details on what you are injecting?

[dmoka]

In the Hydration parachain, we want to inject custom functionalities into all utility batch calls, both before and after their execution.

Could you give some more details on what you are injecting?

Within Hydration, we decided to implement a unified Swapped event emitted by all our AMMs. For each event, we need to understand its context—whether it originates from our DCA, Router, ICE, or Utility Batch. To achieve this, we need to track the context, and this tracking logic would be injected both before and after Utility batch calls.

Here is the exact code that we want to inject, we are already doing this in a PR with the fork of polkadot-sdk

https://github.com/galacticcouncil/hydration-node/blob/04c19428d8b76eb13dbccfd0bbaf1fc95d77cbf0/runtime/hydradx/src/system.rs#L320-L337

[dmoka]

Any update on this @bkchr ? Let us know if you need any further info to proceed with it, thank you.

[bkchr]

Could just be one trait.

[bkchr]

Any update on this @bkchr ? Let us know if you need any further info to proceed with it, thank you.

I actually started to review, but forgot to press the button. Generally I think it is fine, we should just combine the functionality into one trait.

[bkchr]

https://github.com/galacticcouncil/hydration-node/blob/04c19428d8b76eb13dbccfd0bbaf1fc95d77cbf0/runtime/hydradx/src/system.rs#L320-L337

One thing that came to my mind while looking into this, you could use dispatch_context to keep track of the id stack.

[gui1117]

/cmd prdoc --audience runtime_dev

[gui1117]

Looks good to me, maybe one trait BatchHook.

Also we can have a small prdoc as people still have to add the associated type in their runtime.

[shawntabrizi]

Looks good to me. I might consider wrapping the error from the hook into a pallet specific error, but may not be needed.

Consider it will def be easier to trace when an error is appearing.

[bkchr]

Suggested change

	///Hook to be called before any batch operation
	/// Hook to be called before any batch operation.

[bkchr]

Suggested change

	pub trait BatchHook {
	fn on_batch_start() -> sp_runtime::DispatchResult;
	fn on_batch_end() -> sp_runtime::DispatchResult;
	}
	impl BatchHook for () {
	/// Hooks that will be called for `batch` calls.
	#[impl_trait_for_tuples::impl_for_tuples(30)]
	pub trait BatchHook {
	/// Will be called before a batch is executed.
	fn on_batch_start() -> sp_runtime::DispatchResult;
	/// Will be called after the batch was executed.
	///
	/// Depending on the exact batch call used, it may not be called when a batch item failed.
	fn on_batch_end() -> sp_runtime::DispatchResult;
	}
	impl BatchHook for () {