op-node: Move withdrawal utils out of node into op-e2e

[ajsutton]

Description

op-node: Move withdrawal utils out of node into op-e2e.

These are intended to be utilities for e2e tests so shouldn't live with the production code in op-node.

Additional context

This likely still creates a problem for Base's withdrawer tool - see #9765 Keeping as a draft until we settle on a plan but figured I'd put this up so CI can run tests and see if it does break anything.

If we intend to make these withdrawal utilities supported we probably should put them in a top level package or move them to op-service (and clean them up and test them a lot better). They don't actually get used by op-node so doesn't make sense to keep them there.

[mdehoog]

@ajsutton thanks for the review and merge of #9765.

I understand the desire to move this package to the op-e2e group. If that happened, we would probably extract this and maintain our own. However I would like to put a vote in for keeping this where it is, simply because it's nice to have a Golang implementation of withdrawal logic. I would argue that just because it's only used in E2E testing, doesn't mean it doesn't serve a purpose as a separate Golang package that can be used by other Golang tools for withdrawals.

For example, we have Golang tools that perform automated withdrawals from our vaults into our batcher/proposer addresses, which depend on this logic.

I like your idea of moving to op-service 👍

[ajsutton]

Yeah I agree it can be a useful library. Any chance you'd have time to move it to op-service and maybe tidy it up a little and see if we can improve testing? Doesn't have to be perfect but at the moment I think it still "looks" like e2e utils so people don't realise they shouldn't introduce e2e dependencies.

I don't actually know what I'd change yet - I could have a play but open to any ideas.

[tynes]

The same way that geth has abi packages, op-node could have withdrawal packages. But we do have a monorepo so i could see the argument for moving it out of op-node proper. We need an official sdk (in any language) so that we can deprecate the ts sdk completely and have people use viem when using typescript. viem team is only comfy with maintaining the only ts sdk if there is at least another sdk in any language

[ajsutton]

I do think op-service is probably the right place for this but don't have time to try and push this forward at the moment. I suspect that currently the code looks enough like a test utility that we are very likely to re-introduce issues like depending on op-e2e again in the future. The impact of that was pretty low though so if it happens again we can look further into how to fix it better.