Hooks

[spengrah]

This PR creates a new version of MCH that adds an optional hook to be called when a hat is claimed.

For example, a hook could be set up to claim signing permissions in HatsSignerGate in the same transaction during which the signer hat is claimed.

[spengrah]

I'm interested in reviewers perspectives on how the implementation effects other parts of the hats stack, such as the ancillary subgraph, main app, and claims app. Obviously adding hooks will require changes to other areas of the stack, but I want to make sure that those changes are sane and as simple as possible.

I've endeavored to preserve all existing functionality, ie i've added new claim...WithHook and set...AndHook functions rather than inserting the hook logic into the existing functions. Do you think that's the right move?

Also, the hook set event is singular, mainly because there will be times when an org wants to deploy a new MCH instance with claimable hats where some of those don't have hooks, and I didn't want to have to dynamically create/populate arrays to fit into batch hook set events. Do you think that would create difficulties or complications for the subgraph?

[spengrah]

I've deployed test contracts to sepolia as a demo for using a mint hook to claim a hat and HSG signer permissions in a single tx. You can see it in action here:

• tree: https://app.hatsprotocol.xyz/trees/11155111/845
• mint hook contract: https://sepolia.etherscan.io/address/0x1C89802a2DC5f463BE46bc8e7f35B8c602B8d4cD
• MCH instance (with hooks): https://sepolia.etherscan.io/address/0xf25c2a63AB91Ce849A901E9A890B23FDF0677Fa6
• HSG v2 instance: https://sepolia.etherscan.io/address/0x334a84dBaa6e4d458Bf9C96A3890B110ab35Fb9d
• Safe: https://app.safe.global/settings/setup?safe=sep:0xF07A7B7FcADdDD15F631E1A599B819Ca950EC65f