Alchemy ERC-4337 Paymasters

In a `mode` of `0`, `1` and `2`, the paymaster expects repayment in some ERC20 token and possibly returns excessive prepayments back to the `UserOp.sender`. However, reverts of the `postOp()` call can result in this process to no being properly completed, as the state from the execution phase, but not from the passed validation phase, is rolled back in those cases. * `mode 0` and `mode 2`: user fully pays upper bound pre-payment, but is not getting potential excess funds back. In these modes, the Paymaster temporarily holds the funds, so reverts are limited to strange, non-standard ERC-20 behavior. However, if such a case were to happen, these ERC-20 tokens would now be stuck in the Paymaster of a possibly significantly overcharged `maxTokenAmount` amount of tokens. There is no mechanism to redeem those tokens again for anyone. They can also not be withdrawn from the paymaster, as the paymaster itself is currently not designed to be holding ERC-20 tokens permanently, instead it normally forwards the charged amount to the `receiver` address. * `mode 1`: This mode expects an approval to be set as part of the execution phase. If that does not happen as simulated or if the tokens get sent out the account before the `postOp()` call, the Paymaster does not receive any reimbursement from the user, as in this mode, the transfer is only completed in the `postOp()` call after the execution phase. In the V0.6 Paymaster, the user therefore fully gets away with a free UserOperation, as reverts are not performed as that would harm Paymaster reputation. In the V0.7 Paymaster, there is a revert, rolling back the execution phase of the UserOperation, but this still poses a griefing attack on the Paymaster, as the Paymaster is still required to pay for the reverting UserOperation without getting reimbursed.

As of V0.7, the EntryPoint will no longer forward a `PostOpMode` enum of type `PostOpMode.postOpReverted`to the paymaster; hence, it's check in the V0.7 paymaster in the `if` statement can be skipped. However, in V0.6, that parameter value would indicate that something malfunctioned in the intended flow of this Paymaster. Especially reverts in the first `postOp()` call in case `mode = 1`, i.e. in the case that the ERC-20-payment is supposed to be collected in the `postOp()` call, would indicate that the user was not billed for the sponsored transaction. Therefore, a special event should be emitted here that indicates to enable monitoring for potential abuses.

The EntryPoint v0.6 implementation contains a bug in the invocation of the Paymaster’s `postOp()` function, where reverts with less than 32 bytes of revert data cause the entire bundle to revert. This can result in significant financial loss for bundlers and a banned reputation for the reverting paymaster. The used `safeTransferFrom()` function would revert with a shorter revert message, causing the bug to get triggered. For more info see this [PR](https://github.com/eth-infinitism/account-abstraction/pull/293). In `mode = 0`, the paymaster only performs the `safeTransferFrom()` in the `postOp()` call, which could technically revert, leading to the whole transaction from the bundler reverting.