feat: add support for eth_getBlockByNumber to client

[lpahlavi]

(XC-412) This PR continues the effort to add support for all EVM RPC canister endpoints to the client by adding support for the eth_getBlockByNumber endpoint.

[gregorydemay]

Thanks @lpahlavi for this PR! Some minor comments but otherwise looks already very good to me

[gregorydemay]

Let's maybe create a ticket to add support for those 3 fields, see ethereum/execution-apis#477.

[lpahlavi]

Thanks a lot for the feedback @gregorydemay! Should be good for another round of review.

[gregorydemay]

Thanks @lpahlavi ! There is a minor comment regarding the difficulty post-paris blocks, but otherwise LGTM!

[gregorydemay]

nit: this is not just serialization, but also some form of canonicalization to be able to compare it with the other serialized type. It might be clearer if all mutations happen in some canonicalize methods, e.g.

#[test]
        fn should_convert_pre_paris_block_to_alloy(block in arb_pre_paris_block()) {
            let serialized = serde_json::to_value(&block).unwrap();

            let alloy_block = alloy_rpc_types::Block::try_from(block.clone()).unwrap();
            let alloy_serialized = serde_json::to_value(&alloy_block).unwrap();

            prop_assert_eq!(serialized, canonicalize(alloy_serialized));
        }


fn canonicalize(block: serde_json::Value) -> serde_json::Value { //take ownership to return mutated type

}

[lpahlavi]

Makes sense. I've extracted the canonicalization logic to a separate method and applied it to both serialized objects. Theoretically, it's only really needed to canonicalize serialized in should_convert_post_paris_block_to_alloy to ensure that there are no null difficulty values, but I thought it's then clearer to just apply the same canonicalization to both sides of the equation in all tests for clarity. WDYT?

[gregorydemay]

but I thought it's then clearer to just apply the same canonicalization to both sides of the equation in all tests for clarity. WDYT?

This part is less clear to me, the canonicalization does not do anything in case of the Candid type, or am I missing something? If that's the case I actually find it confusing to have it (could also be error-prone in case a field is wrongly set to some value in both cases that does not match the actual behavior of the productive logic)

[lpahlavi]

Actually, there is one edge case where the serialized evm_rpc_types::Block needs to be canonicalized. Namely, when the difficulty field is null which would correspond to 0x0 for alloy (since there the difficulty is never null). This is however just needed in the post Paris upgrade test. I extracted that canonicalization and applied it more restrictively, only where needed.