Add little command for easy access to JSON-RPC interface

[lithp]

This is a much less ambitious version of #169 and replaces it.

Example output:

$ cargo run -p trin-cli -- discv5_routingTableInfo
Attempting RPC. endpoint=discv5_routingTableInfo file=/tmp/trin-jsonrpc.ipc
{
  "id": 0,
  "jsonrpc": "2.0",
  "result": {
    "buckets": [
      [
        "0xa133..79e2",
        "enr:-IS4QBD940ObAwu3B4K1ddW15ohedlJW96z04vmJ3W9nKwsOOsQVsN_OZUTLH6zYJrq7GknkHQQ1r24zlSBr6aT6MngBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQNPYMlwKY62uH1WcO38VPTHHHD1CSHPJblkwxvbiwKXW4N1ZHCCEdg",
        "Connected"
      ]
    ],
    "localKey": "0x1c74..82db"
  }
}

(the first line is emitted to stderr, so the output of this command can be piped into jq)

[carver]

Yup, LGTM after tests pass!

[carver]

If you like it, it looks like this could shrink a bit by returning a result from main (with a bit of error tweaking):

Suggested change

	let mut client = match TrinClient::from_ipc(&ipc) {
	Ok(client) => client,
	Err(err) => {
	eprintln!("Could not connect. err={:?}", err);
	return;
	}
	};
	let req = client.build_request(endpoint.as_str());
	let resp = client.make_request(req);
	match resp {
	Err(error) => {
	eprintln!("error: {}", error);
	}
	Ok(value) => {
	// unwrap: this value is safe to serialize, it was just deserialized!
	println!("{}", serde_json::to_string_pretty(&value).unwrap());
	}
	}
	let mut client = TrinClient::from_ipc(&ipc)?;
	let req = client.build_request(endpoint.as_str());
	let resp = client.make_request(req);
	let value = resp?;
	// unwrap: this value is safe to serialize, it was just deserialized!
	println!("{}", serde_json::to_string_pretty(&value).unwrap());

Or, in this kind of one-shot CLI tool, it doesn't bother me to .unwrap() either (as is already used elsewhere in the module).

[lithp]

Great point, just pushed a much shorter version

[carver]

clippy said:

Suggested change

	method: method,
	method,

[carver]

I guess that's only important with an interactive REPL-type tool, rather than this CLI one-shot, right?

[lithp]

Yeah, definitely. I can drop it if you would prefer. This was originally added because I had grand plans of turning this into a client we could use in other parts of the codebase which want to make JSON-RPC calls, such as in the peer tester. You're right that it's unnecessary for current usage but I still think it's useful to have that long-term goal for TrinClient.

[carver]

Yeah, I'm happy to keep it. Maybe just add that little bit of context to the comment.

[njgheorghita]

Looks cool! It'd be nice if you could add a README.md with a couple basic usage examples. On a broader note, I typically use a python script / ipython console to hit the rpc endpoints. The ipython repl is pretty solid for just hitting endpoints ad nauseam. Just curious, how do you see this crate evolving? To play devils advocate just a bit, would distributing a python script be simpler?

[lithp]

Looks cool! It'd be nice if you could add a README.md with a couple basic usage examples. On a broader note, I typically use a python script / ipython console to hit the rpc endpoints. The ipython repl is pretty solid for just hitting endpoints ad nauseam. Just curious, how do you see this crate evolving? To play devils advocate just a bit, would distributing a python script be simpler?

I really wish that distributing a python script was easier, but the second that script uses a library from outside the standard library then it becomes very difficult for anyone who is not a python developer to use, by bundling simple tooling with trin we can make it easy for anyone who can install trin to install the associated tooling.

Unfortunately I will not be around to see it out, but my plan had a couple different prongs:

1. This command is already useful, I can hit ctrl-r from any shell and inspect my trin node's routing table. My next step was going to be adding some JSON-RPC endpoints which allow manually inserting data into the state network, or manually triggering specific TALKREQ commands, having all of these in a little cli seems like it provides some nice debugging UX!
2. Most of the code in this crate is not specific to trin-cli, it's useful anywhere we want to be a JSON-RPC client. This can be pulled out and moved into trin-core and used in other parts of the codebase.