test: mock HTTPS outcalls in state machine tests

[rvanasa]

Adds a mechanism for mocking HTTP requests (based on this MR from ckETH).

Resolves #87.

[gregorydemay]

Thanks @rvanasa for the PR!

[gregorydemay]

@rvanasa : understanding question, taking &self as a parameter to call afterwards self.clone() seems like an anti-pattern. Why not taking directly self as parameter and avoid cloning altogether? (similar question for the fluent methods below)

[rvanasa]

Thank you for the detailed feedback on this PR!

Here is a motivating example:

let setup = EvmRpcSetup::new();

setup.as_controller().authorize(...);
setup.register_provider(...);
setup.as_anonymous().request(...);

Another (more verbose) option would be for the caller to perform the cloning on their end:

let setup = EvmRpcSetup::new();

setup.clone().as_controller().authorize(...);
setup.register_provider(...);
setup.clone().as_anonymous().request(...);

I see the case for switching to the latter if you think that would be preferable.

[gregorydemay]

@rvanasa : It's just that typically with the builder pattern you would do this in a single statement, e.g.,

let setupt = EvmRpcSetup::new()
  .as_controller().authorize(...)
  .register_provider(...)
  .as_anonymous().request(...);

[rvanasa]

I'll do another pass on this while adding more tests. This would be the builder pattern equivalent:

EvmRpcSetup::new()
  .as_controller()
  .authorize(...)
  .as_user()
  .register_provider(...)
  .as_anonymous()
  .request(...);

The reason I'm using the current logic is that it's more explicit about which authorization to use. For instance, removing as_user() or as_anonymous() above could accidentally change the permissions for actions later in the chain. On the other hand, it's certainly more convenient, so I'll continue weighing both of these options.

[gregorydemay]

@rvanasa : additional test ideas (also ok if you prefer to do that in another MR):

1. ensure that the json is correctly sanitized. E.g, query two different providers with the same JSON-RPC request such that both providers return the same JSON content but the string value is different (e.g. fields are ordered differently). Ensure that results provided by the rpc canister are equal in terms of string equality.
2. Ensure that unknown fields in the response are ignored. This ensures that things will keep working if there is a new version of the Ethereum JSON-RPC API

[THLO]

➕

[rvanasa]

Sounds good! I added (1.) in this pull request and will include (2.) separately; tracking in #91.

[gregorydemay]

dumb question: why have another name as the method's name (__ic_evm_transform_json_rpc vs transform_json_rpc)

[rvanasa]

The code above is from a separate Rust library (in lib/rust) which was intended as an alternative to calling the EVM RPC canister. At one point, the canister used this library to perform JSON-RPC requests, but this has changed for the current MVP design.

__ic_evm_transform_json_rpc is provided by the ic_evm library whereas __transform_json_rpc is specific to the canister. They're essentially doing the same thing, so I used arbitrarily different names to distinguish these from each other. I'd be happy to change the names if we can come up with something better.