use minreq instead of jsonrpc http implementation

[conorpp]

The jsonrpc http implementation is hand rolled and has a number of "basic" http issues that we shouldn't have to deal with (missing common headers, content-length parsing issue, etc).

I replaced it with the simple most popular rust HTTP client, reqwest.

[apoelstra]

This increases the number of dependencies from 44 to 180 :) it is completely dead-on-arrival for that reason alone.

I appreciate the frustration with "basic" HTTP issues but for some reason the Rust ecosystem does not have a single HTTP client crate that can do simple things (like exchanging ASCII-encoded JSON with a daemon we can trust to be reasonably well behaved) without pulling in 100+ dependencies.

If you have specific issues with rust-jsonrpc we'd really appreciate bug reports. At some point we do intend for it to be a solid, if not full-featured, HTTP client, but we have limited usage data to work with.

[conorpp]

How about https://github.com/algesten/ureq? It would bring dependencies to like 80.

I think to make a good substitute just relying on bug requests over time would be painful. To do it right I think would be to make a dedicated http crate with a suite of HTTP tests. A lot of work, much more simple to use an existing implementation.

[conorpp]

Even better, minireq: only 1-2 deps pulled in.

[apoelstra]

Nice, thanks! We'll take a look.

[conorpp]

updated

[apoelstra]

At some point later today I will PR to minreq with a few fixes:

• They recently broke compilation with the proxy feature by adding some Eq derives inconsistently (at clippy's advice, ironically)
• A couple feature gates are incompatible and can't be used simultaneously, which we would need to fix to use it as a dependency (otherwise our own builds wouldn't reliably compile)
• They have no MSRV, but it looks like every feature but rustls compiles with Rustc 1.48.0, which is fine by us ... but we would want them to have a MSRV policy that's checked in CI, and maybe a promise not to change it by accident.

If the maintainers are friendly and accepting of these changes I see no reason not to use it here :)

[TheBlueMatt]

I'd think they need to also be open to an optional-async feature - if not we'll probably have to implement our own HTTP client anyway one way or another, and I'm not sure why we'd bother with multiple options for HTTP clients.

[tcharding]

We added minreq support to jsonrpc in apoelstra/rust-jsonrpc#94, should we use the minreq_http feature instead of this now?

[tcharding]

Replaced by #341