Allow hook storage to persist on pool no op

[thogard785]

Related Issue

Currently, hook contracts are unable to persist changes to their storage when they filter, postpone, or otherwise block a user's pool operation. This is caused due to the revert() thrown by the pool manager when it receives a non-matching function selector returned by the hook.

Description of changes

New "Return" bytes4 function selectors have been added for each "before" hook to indicate the hook's intention to persist its storage changes while simultaneously blocking the user's pool operation. The PoolManager has been adjusted so that if it receives one of these selectors then it will return a null value rather than revert with error.

The potential usecases for this are broad and only beginning to be explored. This upgrade will be especially empowering on chains other than Ethereum Mainnet that are conducive to more complex and sophisticated hook design due to their lower gas costs.

Some examples:

• Storing transactions sequenced offchain that are being mined out of order by an adversarial builder.
• Storing a swap matched with a queued just-in-time liquidity add, executing the liquidity add, doing the swap, then removing the liquidity add.
• Fork-sequenced meta transactions.
• Frontrunning protection for individual meta transactions in an account-abstracted bundle.
• Direct integration with smart wallets that may need to "clear" inventory prior to executing a user's trade.
• Inducing the first swap for each block to be a meta transaction bundle of auction bids from searchers and allocating the MEV proceeds to the liquidity providers to offset impermanent loss by postponing (rather than censoring) transactions that occured earlier in the block. A illustration of this concept can be found here: https://github.com/Polygon-Fast-Lane/atlas/blob/main/src/contracts/v4-example/UniV4Hook.sol#L440

[zhongeric]

Thanks for opening a PR @thogard785 ! Can you make sure your commits are signed as that's a requirement for incoming PRs :)

[thogard785]

Thanks for opening a PR @thogard785 ! Can you make sure your commits are signed as that's a requirement for incoming PRs :)

@zhongeric - sorry about that! I just rebased / squashed the commits with a signature, so it should just be one signed commit now. Let me know if there's anything else that's needed. thank you.

[ewilz]

fyi, if we go with the second PR referenced here, we'll definitely get your commit included in there, so you'll get credited

[thogard785]

fyi, if we go with the second PR referenced here, we'll definitely get your commit included in there, so you'll get credited

Thanks!

[ewilz]

closing in favor of of #299 just to clean things up. we are exploring no-op but taking it a step further and iterating internally. if we decide to incorporate no-op, we'll include your commit as I believe this was at least in part the impetus for some of our ideas.