✨ Add new calldata optimal execution mode for ERC7821

[legion2002]

Description

The PR adds a new calldata optimized execution mode to ERC7821 which allows you to batch calls to the same target address, without sending the redundant "to" variable in each call.
It also removes the value field, and assumes it will be 0 for all the calls. This is usually true for most DeFi batches, because everything uses WETH.

Even if the address(0) optimization is used in calldata, for each call there is still a 4 gas overhead.
With this PR, you can compress the calldata down to the theoretical optimal, this is specially useful when you want to do highly optimized self calls.

Note: The address(0) replacement is still available with the common to field passed.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

• Ran forge fmt?
• Ran forge test?

Pull requests with an incomplete checklist will be thrown out.

[atarpara]

@legion2002 bounds checks for CallSansTo[] is missing.

[Vectorized]

i’ll work on this after i wake up. brb sleep now.

[legion2002]

Thanks @atarpara, I maybe missing something, but doesn't solady intentionally skip these bounds checks, as mentioned here?

I was following the same pattern as how we treat the standard Call struct, do we do bounds check for that somewhere?

[Vectorized]

@howydev @legion2002 @atarpara

Upon further thinking, this is actually more non-trivial than expected.

First, ERC7821 does not make any bounds checks. This is intentional (Solady tries to cater to max performance under expert use, freedom to bear footguns).

We expect that users who require checks use LibERC7579.decodeBatchAndOpData and LibERC7579.decodeBatch.

The reason why ERC7821 does not have the checks is because we expect that the executionData will be checked once via LibERC7579 somewhere else, when it matters. For Ithaca's case, that check is in the the _computeDigest functions, since in cases with both validation AND execution, the offsets of executionData can be different.

If we want to put this on ERC7821, we will need LibERC7579.isCompactBatch and LibERC7579.decodeCompactBatch.

Maybe can do this just on the Orchestrator, if all the intents will be done via the Orchestrator. I'm currently thinking if this is actually worth the effort. There is some overhead in detecting a compact representation, and re-encoding it. I'm thinking of simply abi.encode(address to, bytes[] calldatas). Also, the updated re-encoding function will need all the hardcore checks.

[legion2002]

@Vectorized @atarpara I have now updated the PR to remove the CallSansTo struct, and replace it with an array of data values.
So this should be the theoretical optimal calldata mode for most common DeFi interactions.

We could also do RLE encoding, but I think it won't have that big of a gas improvement, because 0 bytes are already priced 1/4th the value of non zero bytes.
We could think of adding this down the line, but for now I think this level of optimization should be good enough.

[Vectorized]

@legion2002 I think i'll make a vendor subdirectory for ithaca for to unblock, without needing to change ERC7821. Else other vendors will need to update their ERC7821 related stuff.

Note: ERC7821 allows address(0) as an alias for address(this) in to, which makes it pretty good for RLE.

I'll go make a writeup on how EIP8022 could be made into a precompile. Ideally, we can braindead RLE everything.