Add withdrawal functionality to sequencer entrypoint

[karlfloersch]

Is your feature request related to a problem? Please describe.
We are currently unable to withdraw funds that are sent to the sequencer entrypoint. This is annoying because the ECDSAWallet contract will send all fees to msg.sender -- normally the sequencer entrypoint & the sequencer needs to be able to withdraw fees collected to pay for the batches the sequencer submits!

Describe the solution you'd like
Simply add a function withdrawFees() owned returns() to the sequencer entrypoint.

This function should:

• withdraw the FULL BALANCE of the sequencer entrypoint to the l1FeeWallet
• l1FeeWallet can be RESOLVED by the L2 Address Manager
• Be OWNED by an L2 contract. This contract can be an ECDSAWallet & can be resolved by the address manager.
  • Many options here, do what is easiest.

Describe alternatives you've considered
Instead of withdrawing the full balance, you can simply SEND the full balance to the OWNER. This may be slightly easier as we don't need to resolve some L1 fee wallet. However, it will require 2 transactions to perform with withdrawal -

1. Send full balance to the owner
2. Owner withdraws its full balance.

---

Additional context
Note that there is another way to allow the sequencer to withdraw fees that requires a change to the ECDSAContract wallet.

• Hard code a "fee collector" wallet in the ECDSAContractAccount.
• Send the money to the hardcoded wallet.

That approach is not suggested based on the following tradeoffs:

1. Hardcode the sequencer’s fee address
   a. The most efficient, requires a bit more implementation complexity as now the sequencer needs to manage two upgradable contracts & we need to add a new predeploy. Also it does introduce an implicit dependency with the hardcoded address in the wallet. Meaning if we change the predeploy address we could accidentally break wallet fees
2. Use msg.sender (status quo) and add a function to withdraw the funds in the sequencer entrypoint
   a. Medium efficiency. Requires a CALL and an SLOAD (see)
   b. Has the benefit of making it possible to pay a fee to folks other than the sequencer. This might have been the original thing that made us prefer # 2 over # 1

Tradeoffs:

• Efficiency
  • Winner: # 1 — Probably saves like 1k gas per wallet transaction. (I got 1k from ~700 gas for the CALL & then ~100 for the warm SLOAD read, and then 200 gas for who knows what)
• Implementation complexity
  • Winner: # 2 — This is the status quo, doesn’t introduce a new predeploy or change EOA accounts
• Flexibility
  • Winner: # 2 —
    • No risk of the hardcoded address getting out of sync with the predeploy address
    • Allows fees to be paid to anyone who relays the transaction, not just the sequencer. IMO this is less important as it’s not a feature folks will use any time soon.

[smartcontracts]

Completed in #1029