refactor: Related #9459 - evmbin: replace untyped json! macro with fully typed serde serialization using Rust structs

[ltfschoen]

Purpose: Refactoring to replace untyped json! macro of #9489 with fully typed serde serialization using Rust structs for reusability and allows customization of how each field is encoded/decoded (i.e. camel case)

• - Move changes that are unrelated to the goal of this PR into a separate PR refactor: Refactor evmbin CLI #10742 and PR refactor: Fix indentation in ethjson #10740

• Mentioned related issue e.g. Fixes #228 or Related #1337.

• - Rename multirust (deprecated) to rustup
• - Initial update of evmbin Rust docs and code comments
• - Add Response struct and implement it in response
• - Remove serde imports that aren't used
• - Fix linting by converting from camelcase to snakecase properties as required
• Is this PR even necessary? Hasn't evmbin: replace hardcoded json output logic with serde serialization #9459 already been addressed in PR Replace hardcoded JSON with serde json! macro #9489. Ans: Yes, see refactor: Related #9459 - evmbin: replace untyped json! macro with fully typed serde serialization using Rust structs #10657 (comment)

• Labeled PR with appropriate labels
• PR adheres the style guide

• Updated any rustdocs which may have changed
• Implement serde json instead of json! wherever it is used apart from just TraceData
• Replace untyped json! macro use with typed serde json TraceData in json.rs and std_json.rs. Status: resolved resolution of the Clone errors.

**Question** (solved) in json.rs i replaced use of the untyped json! macro with serde serialization, and i had to use `informant.clone()` here https://github.com//pull/10657/files#diff-98c535329ae4c9199c5b7ddd6b06b5baR85, so i had to add `Clone` to the struct here https://github.com//pull/10657/files#diff-98c535329ae4c9199c5b7ddd6b06b5baR30, and when i ran the tests they passed.

but when i did the same thing of using informant.clone() in the std_json.rs file here https://github.com/paritytech/parity-ethereum/pull/10657/files#diff-7c765744595c52ae7a64296e4264971cR206, and added Clone to the associated struct here https://github.com/paritytech/parity-ethereum/pull/10657/files#diff-7c765744595c52ae7a64296e4264971cR55, i get heaps of errors wrong number of type arguments: expected 3, found 2.
but when i add the additional first type as either Clone or clone::std:clone::Clone to address all the errors in commit 42ebcf7, when i run the tests again with cargo test -p evmbin --release -- --nocapture i get a new set of errors, and heaps of them that include: the trait std::clone::Clone cannot be made into an object, and doesn't have a size known at compile-time (which i suspect i'd resolve with lifetimes).
i could continue trying to fix those errors, but i think i've done something wrong.

• Answer based on discussion with @tomusdrw, instead of stack: informant.clone().stack, where we clone the entire informant and have to add Informant<Clone, it could instead be informant.stack.clone(), however we can do better by not cloning the stack and storage and rather borrowing, it involves some lifetimes, but doesn't require cloning at all.

• Fix move out of borrowed content error by cloning instance of Informant struct with Clone
• Fix failing tests and add new

cargo test -p evmbin --release -- --nocapture

Check that it works by copying create2callPrecompiles.json and teststate.json from #10742 and run:

./target/release/parity-evm state-test ./evmbin/res/create2callPrecompiles.json --only create2callPrecompiles --chain Constantinople --json

./target/release/parity-evm state-test ./evmbin/res/teststate.json --only add12 --chain eip150 --json

• - Remove debugging

[parity-cla-bot]

It looks like this contributor signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[ordian]

@ltfschoen I think the #9459 was already resolved by #9489, but adding more docs is welcome.

[ltfschoen]

Closing as this task has already been completed!

[sorpaas]

@ordian i still think some of this PR can be useful -- replacing macro with fully typed serialization is a little bit better IMO. My opinion is that, not only we may be using it somewhere else in the future, but also, it allows us to customize how each field are encoded/decoded (camel case!) so it's a little bit more rusty. :)

WDYT?

[ordian]

@sorpaas I agree the refactoring to use rust structs is better than untyped json!, though I think the original issue was resolved. Sorry I didn't mean we should close this PR.

[ordian]

@dvdplm could you take a look again?

[dvdplm]

minor grumble