feat(rpc): add rpc methods to enable/disable other cheatcodes

[0xzrf]

Closes #543

Summary

This PR adds new rpc methods to the SurfnetCheatcodes trait to disable and enable different cheat codes

What Changed

• Added disable_cheatcodes, enable_cheatcodes, lockout, disable_all_cheatcodes rpc methods
• Added a CheatcodeConfig struct, CheatcodeFilter enum and RpcCheatcodes in surfpool-types crate. Here's the description for each:

/// main control handler
pub struct CheatcodeConfig {
    pub lockout: bool, // if true, allows disabling even the `surfnet_enableCheatcodes`/`surfnetdisableCheatcodes` methods
    pub filter: CheatcodeFilter,
}

pub enum CheatcodeFilter {
    #[default]
    All, // Disabled all the cheatcodes
    List(Vec<String>), // disables cheatcodes in a named list
}
// a list of all the cheatcodes rpc method names. Used to convert between rpc method name to enum value
pub enum RpcCheatcodes {
     CheatcodeRpcMethods.....
}

• Added cheatcodes_config: Arc<Mutex<CheatcodeConfig>> to RunloopContext struct to allow cheatcode method filtering between RunloopContext and SurfpoolMiddleware
• the surfnet_disableCheatcode and surfnet_enableCheatcode majorly just push to the CheatcodeFilter::List
• Added code to filter out cheatcode rpc methods that are in the CheatcodeFilter::List variant(And rejects all the cheatcode rpc calls when CheatcodeFilter::All)

        if RpcCheatcodes::try_from(method_name.as_str()).is_ok()
            && let Some(meta_val) = meta.clone()
            && meta_val
                .cheatcode_config
                .lock()
                .unwrap() // this is okay since only on_request, disable_cheatcode and enable_cheatcode only use it, the rpc method being called after on_request
                .is_cheatcode_disabled(&method_name)
        {
            let error = Response::from(
                Error {
                    code: ErrorCode::InvalidRequest,
                    message: format!("Cheatsheet rpc method: {method_name} is currently disabled"),
                    data: None,
                },
                None,
            );
            warn!("Request rejected due to cheatsheet being disabled");

            return Either::Left(Box::pin(async move { Some(error) }));
        }

• the lockout and disable_all_cheatcodes basically manipulate the state inside the CheatcodeConfig struct, while the CheatcodeConfig::is_cheatcode_disabled() handles whether to reject the request or not
• Added tests for the workflow in crates/core/src/tests/ingration.rs:test_enable_and_disable_cheatcodes

Context

This PR is motivated by the issue #543 and (hopefully) adheres to mostly all the code expectation provided by @MicaiahReid , except the admin control(More then happy to add that too once I get some clarity on that part)

[MicaiahReid]

This is awesome. The core internal logic is there, but I'd like to simplify the RPC interface a bit.

I'd like to keep all of the same functionality you've implemented, but only have a total of two new RPC methods:

• surfnet_enableCheatcode
• surfnet_disableCheatcode

When disabling a cheatcode, you can optionally provide { lockout: true } to allow disabling surfnet_enableCheatcode. For the enable/disable method, a list of methods can be provided, or just the string "all".

Here are some example requests.

Enable all cheatcodes (if `surfnet_enableCheatcode` is enabled)

**Note**: if previously `surfnet_enableCheatcode` was disabled, this would return an error ```JSON { "jsonrpc": "2.0", "id": 1, "method": "surfnet_enableCheatcode", "params": [ "all" ] } ```

Disable all cheatcodes (except `surfnet_enableCheatcode`/`surfnet_disableCheatcode`, since no lockout option provided)

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_disableCheatcode",
  "params": [
    "all"
  ]
}

Disable the set account + set token account cheatcodes

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_disableCheatcode",
  "params": [
    ["surfnet_setAccount", "surfnet_setTokenAccount"]
  ]
}

Disable the set account + set token account cheatcodes

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_disableCheatcode",
  "params": [
    ["surfnet_setAccount", "surfnet_setTokenAccount"]
  ]
}

Disable `surfnet_enableCheatcode`

If we didn't provide `{"lockout": true}` the method would return an error, saying to disable this cheatcode you need to provide the flag ```JSON { "jsonrpc": "2.0", "id": 1, "method": "surfnet_disbleCheatcode", "params": [ ["surfnet_enableCheatcode"], { "lockout": true } ] } ```

Hopefully those examples help clarify!

[0xzrf]

@MicaiahReid what happens in the case when surfnet_disableCheatcode with {lockout: true} disables surfnet_enableCheatcode and then surfnet_disableCheatcode is called with params: [ "all" ]?

In other words, how will providing surfnet_disableCheatcode with lockout and "all" param influence whether surfnet_enableCheatcode is enabled or disabled?
Thanks

[MicaiahReid]

@0xzrf all of this enable disable endpoint and disable enable endpoint language is so confusing 🤣

lockout on surfnet_disableCheatcode is allowing the surfnet_enableCheatcode endpoint to be disabled. Once that endpoint is disabled, there's no going back without killing your network.

This disables the surfnet_enableCheatcode:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_disableCheatcode",
  "params": [
    ["surfnet_enableCheatcode"],
    {
      "lockout": true
    }
  ]
}

This disables the surfnet_enableCheatcode and all other endpoints:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_disableCheatcode",
  "params": [
    "all",
    {
      "lockout": true
    }
  ]
}

Does this answer your question?

[0xzrf]

Thanks, that was helpful
I'll end this enable disable language battle asap🤭

[MicaiahReid]

Can we also remove the unwraps on the locks?

[MicaiahReid]

Just FYI @0xzrf, I pushed d1843a7 to this, which automatically generates the list of potential cheatcodes rather than us having to maintain that enum you'd created in the types.rs

[0xzrf]

Just FYI @0xzrf, I pushed d1843a7 to this, which automatically generates the list of potential cheatcodes rather than us having to maintain that enum you'd created in the types.rs

yeah, design wise, I think this is a better approach. Thanks for the fix

[MicaiahReid]

I think this is looking good, thanks for the hard work @0xzrf!

I'd like to get architect extrordinaire @lgalabru's opinion before merging to see if he has any concerns.