Embed intent hash within permit

[ScreamingHawk]

This makes the entrypoint.depositToIntentWithPermit flow only require a single signature.

1. Hash the intent params to make intent_hash
2. Set the top byte to 0xff
3. Use this hash as the permit_deadline for the permit call
4. User signs the EIP-712 Permit payload with this permit_deadline acting as a nested intent_hash

Setting the top byte of the intent_hash (i.e. permit_deadline) to 0xff makes intent_hash > block.timestamp always true, without significantly impacting the chance of a hash collision.
As all intent parameters are hashed and included in the signed permit call, we can trust that the intent is approved if the permit signature is valid.

Caveat: The user will be signing Permit(owner=wallet_addr, spender=trails_entrypoint, value=uint256.max, nonce, deadline=permit_deadline) which hides the intent parameters from the user's wallet when signing.

Caveat: This removes front run protection added here: #75. If we want to re-enable this protection, we could perform a duplicate of the ERC20's permit signature validation on the entrypoint itself. This would require duplicating the permitNonce too. I think this is overkill as the front run attack is unlikely to be exploited in practice. The user can re-sign and use depositToIntent instead.

Potential caveat: The user must sign a Permit call with a higher deadline than they may want. This could be replayed or frontrun directly to the ERC20. This should be fine, since those approved funds are still only accessible with a user signature (either the same one if committed through entrypoint.depositToIntentWithPermit or a second one if accessed via entrypoint.depositToIntent). The entrypoint.depositToIntentWithPermit call is still only valid for the intent deadline and not the extended permitDeadline.

Consider: For depositToIntentWithPermit, signature validation is entirely done by the ERC20 token. This means a buggy or overly permissive permit validation will allow approved funds (for this buggy token only) to be exploited via the entrypoint. I don't think this is a concern. If the user is using a buggy ERC20 then that's not really our fault...

[ScreamingHawk]

This PR has a few caveats so I suggest we consider the trade-offs are worth it. This requires changes throughout the stack to handle the entrypoint interface changes and new permit signature encoding.

[Agusx1211]

This is a very cool idea. For the "we lost the deadline" problem, we could slightly modify this so instead of encoding the intent on the deadline, we encode the intent in the address that we approve.

This address would need to serve a dual purpose (1) be the "first signature" for the first intent and (2) become the entrypoint of tokens of all subsequent intents. This frees the deadline to become the real deadline again. The downside is that now every user has their own address that they sign permits to.

---

Unless we come up with a design that does not hide the intent parameters from the signature, it would be nice to know what does the product team prefer. We have two options:

a) Keep intent typed signatures fully defined, so the user is always presented with the information they are signing, but we would still need 2 interactions the first time the user interacts with a token + chain combo.

b) Do something like the proposed change, which gives us a path for "always 1 click" interactions, but sometimes the intent typed data is effectively hidden.

[pkieltyka]

Thanks for the PR, lets skip it for now