Fix gnosis preset issue

[nflaig]

Motivation

Issue reported here https://discord.com/channels/593655374469660673/743858262864167062/1069661074556719175

In v1.4.0 it is not possible to use any preset other than mainnet and minimal because the dev.ts is always executed which checks for those and otherwise throws an error.

lodestar/packages/cli/src/networks/dev.ts

Lines 5 to 14 in be9b9a0

	switch (ACTIVE_PRESET) {
	case PresetName.mainnet:
	chainConfig = mainnetChainConfig;
	break;
	case PresetName.minimal:
	chainConfig = minimalChainConfig;
	break;
	default:
	throw Error(`Preset ${ACTIVE_PRESET} not supported with dev command`);
	}

Description

Use getters to load network data, this allows to add additional logic (as it is done for dev) and also only loads the network data into memory if it is actually used.

Add gnosis preset to dev command

[twoeths]

looks good to me!

[wemeetagain]

Instead of adding a network specific getNetworkData, I think we can just add another case for PresetName.gnosis. (And perhaps remove the default case)

[wemeetagain]

(We probably want to support any preset for the dev command anyways)

[nflaig]

The main reason for adding a function to get the network data is that we only want to execute this switch-case statement (or any other network specific code for that matter) if the network is dev. If we don't use a function this will always be executed which is unnecessary/unintuitive.

[nflaig]

I think we can just add another case for PresetName.gnosis

lets do this for now as it is less overall changes to get this fix out asap, I still think it is not a good that we execute code related to dev command if we run other commands such as beacon

[wemeetagain]

Agree that its not great to be running this code, just looking for the smaller diff for quick fix.

Also looked into turning the network imports into an await import but that also is a big change since getNetworkData and some downstream consumers are all sync functions

[nflaig]

Also looked into turning the network imports into an await import

yeah that was also the initial solution I wanted to use until I figured that the downstream call chain just never ends and had like 30+ changes, I still have most of those changes stashed if we want to apply this solution later

[wemeetagain]

🎉 This PR is included in v1.6.0 🎉