feat(genesis): Deserialize ChainConfig from toml

[cakevm]

Allow to read ChainConfig from a toml file. The network configuration is stored as toml in superchain-registry. The genesis files do not contain always the config field e.g. base.json.zst contains "config":null. Step toward resolving: paradigmxyz/reth#14240

Changes:

• Allow parsing from json and toml
  • serde_alias introduces unmaintained exception for proc-macro-error
• Allow to parse Genesis from missing config field and "config":null

@mattsse

[mattsse]

hmm, I see, we need this to check whether the json file contains a config object or not?

I think we can make paradigmxyz/reth@main...cakevm:reth:superchain-config#diff-794272b13b0060335d4f5e2cf4cb1021c60aa195b66326ce6907266b5f9ca6f5R18 work with if we do an extra step and deserialize into value first and check if the config field is null?

[cakevm]

Yes, you are right. I removed the DefaultOnNull and will patch the json if required. Second as you suggesting I will load the config only when required.

[cakevm]

I gave the topic a fresh look and mixed up to different types here. Sorry for that, this PR does not makes sense.

There is op-geth the type, used for the json, is defined here:

type Genesis struct {
	Config     *params.ChainConfig `json:"config"`
	Nonce      uint64              `json:"nonce"`
...
type ChainConfig struct {
	ChainID *big.Int `json:"chainId"`
...

It looks like config can be null here. I still looking for the reason why there is `"config": null" at all.

Second there is Chain in superchain-registry here used for the toml:

type Chain struct {
	Name                 string              `toml:"name"`
	PublicRPC            string              `toml:"public_rpc"`
...

I am considering proposing to allow None for the config field and introduce a new struct for the superchain chain config. When I found the reason for the null.