feat(params): UnmarshalChainJSONConfig and MarshalChainConfigJSON

[qdm12]

Why this should be merged

• Allow wallets and other clients to parse blocks from both coreth and subnet-evm without registering extra types
• Allow wallets and other clients to make their genesis/chain configurations without registering extra types

How this works

• UnmarshalChainConfigJSON is a standalone deserialization function taking a data byte slice, the destination pointers *ChainConfig and a generic extra *C, as well as a reuseJSONRoot boolean.
• MarshalChainConfigJSON is a standalone serialization function taking a ChainConfig, an extra of generic type C and reuseJSONRoot boolean.

How this was tested

New unit tests TestUnmarshalChainConfigJSON_Errors and TestMarshalChainConfigJSON_Errors for unhappy code paths, existing test TestChainConfigJSONRoundTrip for happy code paths.

[darioush]

nice, let's add MarshalJSON, we can do it in this or a separate PR

[ARR4N]

(style) Please don't use such verbose variable names when the scope is only 3 lines; they distract from reading of the code. I'd personally be happy with just r, but understand that others are not—as long as it's not 5 syllables.

See style guide

[qdm12]

I've read a few style guides including that one, my view on it, unless it's a really obvious use (i.e. i for a range index), it's nice to have a meaningful name almost always. For example c instead of extraConstructors made me wonder what was c and had to lookup where it was created and what .Get() was returning, and, because it's a generic function, had to dig into extraConstructors struct. Not a big deal obviously, but it does make readability worst in my opinion.

Obviously that's my opinion on this, so I'll conform to the existing code and use shorter variable names 😉

EDIT: also one more reason is I do like to use a single letter for the receiving struct for methods, so using single letter variables in there makes things confusing imo

EDIT2: my brain is kind of very formed (malformed or ok-formed, debatable 😄) to use explicit non-single-letter variable names, so feel free to hammer with style comments in case you feel like it should be a smaller variable name. I got the extraConstructors -> ec but after going through the rest of the code I wrote, I'm feeling like:

[ARR4N]

The rest of libevm uses "want" instead of "expected" and "got" instead of "actual".

[qdm12]

Changed expected prefixes to want prefixes.
However - ha I want shorter variable names perhaps - regarding actual (and got), I think i.e. data, ok := MarshalXYZ in a test is better than actualData, actualOk := MarshalXYZ and there is no need for an actual prefix really? And if it's only one variable being checked, why not name it to what it actually is i.e. data instead of actual

[ARR4N]

Approving with changes requested because I don't need to re-review them. Most are suggestions (since we're new to working together and sharing my preferred style for libevm) and I'm happy for you to use your judgement in deciding whether or not to implement them, but the following I'd like to discuss if you disagree with them:

1. The 4 external comments on ChainConfig.{Un}Marshal() and on {Un}MarshalChainConfigJSON().
2. All 3 comments on the tests.

[ARR4N]

I think for this and the extras too we should just return a raw error and decorate it in toJSONRawMessages() instead, for consistency. I'd add a suggestion but GitHub review UI sucks and I can't comment on unmodified code in the same file.

fmt.Errorf("encoding %T into %T: %s", v, msgs, err) on line 154.

[qdm12]

I think fmt.Errorf("encoding %T into %T: %s", v, msgs, err) is a bit confusing, since technically we are encoding then decoding into a different Go element (map). I still think converting config to JSON raw messages explains it alright. I've added error wrappings in 359448d66f0a15e7f62b8aaef7bd734872690975 but it might be a bit too-muchey, feel free to let me know and i'll drop that commit.

[ARR4N]

Using a full error message like this is a change-detector test that results in false positives (e.g. they will all break if you accept my suggestions). Alternative options:

1. Limit to a pertinent and specific sub-string for each error.
2. Create (unexported) var errX global variables and wrap them on return, using errors.Is in the test.
3. Create a custom error type with an internal identifier that you can assert here (e.g. although not appropriate, something like gRPC status codes, but unique).

This applies to the marshalling tests too.

See https://google.github.io/styleguide/go/decisions#test-error-semantics

[qdm12]

Agreed, although I would like to add checking error messages does help build decent error messages through error wrappings and avoid repetitions (and also make sure it logs out well formed things, not pointer addresses for example). But the cost of this outweights the benefits, so changing this to an error message regex checking the 'important part' and not the whole error message.