JSON-RPC Client with FULLNODE_API_INFO config & JWT support

[cryptoquick]

Summary of changes
Changes introduced in this pull request:

• Remove jsonrpsee from forest CLI
• Add surf for HTTP requests
• Parse FULLNODE_API_INFO env var to configure HTTP JSON-RPC client
• Pass Authorization header if JWT is provided

Reference issue to close (if applicable)

Closes #1084 and #998

Other information and links
Ran into a snag, so still WIP:
kardeiz/jsonrpc-v2#17

Once I get the RPC client working, I'll refactor other RPC methods

The complexity here came from jsonrpsee not supporting:

• Dynamic variables in macro declarations
• Authorization headers

[cryptoquick]

Sprint carryover update

I got a lot of good work done during last sprint on implementing the majority of what's needed to fulfill this task.

Done

• RPC request building via jsonrpc_v2 (required collaboration with upstream dev on missing serialization trait, since jsonrpc_v2 isn't traditionally used for clients)
• Surf HTTP integration
• Auth header passing (untested)
• Multiaddress parsing via Regex (will update to an approach based on parity multisig as defined in this issue before I mark this as ready, though: Multiaddr::to_url() libp2p/rust-libp2p#2073 )
• Calling RPC functions without parameters
• Fixed serialization issues on Cids
• Fixed CI by bumping Circle rustc to 1.52.1 due to me, a chad rust dev, using freshly stable std lib methods

Doing

• Debugging RPC methods with parameters, which are currently broken due to a deserialization issue
• Multiaddress parsing improvements (replaces regex approach)
• Test JWT creation and passing
• Test all forest CLI methods, with both forest and lotus nodes

[connormullett]

Looks great, will approve once this is R4R if no other changes

[connormullett]

LGTM

[cryptoquick]

This is RFR, but two things:

Errors are not yet parsed correctly, I have an issue upstream for that:
kardeiz/jsonrpc-v2#18

I'll also add in some CLI usage examples in the README while y'all are reviewing

[cryptoquick]

I was just writing this, but then I realized, we should use the auth api-info command instead. That's NYI, though.

### CLI Usage Examples

A tutorial for currently implemented `forest` client workflows.

> forest auth create-token -p admin

Take the JWT output and put it into multiaddress format: ugh n/m, let's wait till we have auth api-info

I'm down to merge this without the usage examples changes and the RPC client error parsing if everyone else agrees.

[connormullett]

I was just writing this, but then I realized, we should use the auth api-info command instead. That's NYI, though.

### CLI Usage Examples

A tutorial for currently implemented `forest` client workflows.

> forest auth create-token -p admin

Take the JWT output and put it into multiaddress format: ugh n/m, let's wait till we have auth api-info

I'm down to merge this without the usage examples changes and the RPC client error parsing if everyone else agrees.

I can add a note to create some usage examples with my work if needed. You and I understand the CLI enough to be able to work with it. Documentation and usage examples can come once we get a good number of commands running I feel

[cryptoquick]

@connormullett Yeah, makes sense. I'll make a separate issue for that work.

[ec2]

LGTM. I think it may potentially be useful for us to have the CLI be able to also use WS instead of HTTP as an option in the future. Just a thought

[ghost]

I only did a shallow code review since this already has two approvals, LGTM

[cryptoquick]

LGTM. I think it may potentially be useful for us to have the CLI be able to also use WS instead of HTTP as an option in the future. Just a thought

I'll make a separate issue for that. It's an entire different transport, so it'd require changes to Multiaddress parsing and some abstraction for a WS client, in addition to surf for HTTP.

[cryptoquick]

I only did a shallow code review since this already has two approvals, LGTM

ty :)

[ec2]

LGTM. I think it may potentially be useful for us to have the CLI be able to also use WS instead of HTTP as an option in the future. Just a thought

I'll make a separate issue for that. It's an entire different transport, so it'd require changes to Multiaddress parsing and some abstraction for a WS client, in addition to surf for HTTP.

Yes, technically, but since the HTTP and WS server are on the same port, you wont need to change the multiaddr parsing. But yeah there will be some heavy lifting done to abstract the client to handle http and ws. Just an idea i have :)