feat: Allow dynamically created custom launchers

[Dzejkop]

How this works

This feature allows one to specify a custom el/cl/builder type in the network params, e.g.

optimism_package:
  chains:
    - participants:
        - el_type: custom

which, can then be dynamically in one's own kurtosis package, e.g.

optimism_package = import_module("github.com/ethpandaops/optimism-package/main.star")

def run(plan, args={}):
  optimism_package.run(plan, args, custom_launchers={
      "el_launcher": {
        "launcher": custom_launcher(),
        "launch_method": custom_launch,
      },
    }
  )

Motivation

We're setting up our own devnet using kurtosis and we're testing our own custom builder. We tried forking/vendoring the whole optimism package and extending it with our own functionality but this is very cumbersome.

I explored if it'd be possible to import optimism-package as a dep, run it and then add our custom builder service later, but the package either deploys with rollup boost & builder nodes or nothing at all. It's possible to setup an external builder but then we need to dynamically figure out the ip address of the host machine as it has to be known ahead of time.

This approach also allows us to benefit from observability integration.

[Dzejkop]

We've tested out this approach on my fork and it allowed us to integrate our custom builder while benefitting from upstream changes in optimism-package worldcoin/world-chain#201

[edobry]

thanks for this contribution! overall this looks like a reasonable approach, but I'm wondering if perhaps it could simplify things if you instead published your custom launcher as a Kurtosis package, and modified the code in this package to support loading the launcher from an external package; thinking this way we could avoid having to add a new top-level argument that could only be set in code, not in a params file, breaking entrypoint parity.

[Dzejkop]

That sounds interesting, I'll explore this idea some time later.

What I'd like to preserve is the ease of development though - I wouldn't want to have to redeploy a package everytime I make some local changes

[edobry]

@Dzejkop understandable, that wouldn't be a great dev experience. Luckily Kurtosis supports replace directives, which can be used with local paths. I strongly recommend pursuing this approach instead, both for the aforementioned reasons and another concern I just realized: what if the user wants to provide multiple custom launchers, from different packages? I'm not sure that would be possible in this PR's current approach.

[emhane]

Suggested change

	name: github.com/dzejkop/optimism-package
	name: github.com/ethpandaops/optimism-package