refactor(api, blocking, async)!: make library generic over any HTTP client

[oleonardolima]

fixes #97

Description

It refactors the library, introducing and adding new structures/enums for Esplora API: TransactionApi, AddressesApi, BlocksApi, and FeeEstimateApi.

Introduce and exposes new trait Client with minimal HTTP behaviors: request, send, send_async, and deserialize_{decodable|json|str} methods.

Any HTTP client can now implement either the send or send_async method, use it's inner HTTP client structure for dispatching and handling the request/response, then use the common already implemented methods for deserializing the response.

Notes to the reviewers

I still think it's not there yet, the ergonomics and usage can be improved, but I'd like to see if anyone has any comments or suggestions on the approach.

Changelog notice

TBD

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added tests for the new feature
• I've added docs for the new feature

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[coveralls]

Pull Request Test Coverage Report for Build 10894551662

Details

• 440 of 521 (84.45%) changed or added relevant lines in 3 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+1.5%) to 89.032%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/blocking.rs	99	118	83.9%
src/async.rs	149	169	88.17%
src/api.rs	192	234	82.05%

Files with Coverage Reduction	New Missed Lines	%
src/async.rs	1	85.49%
src/blocking.rs	2	85.56%

Totals
Change from base Build 10748775132:	1.5%
Covered Lines:	1242
Relevant Lines:	1395

---

💛 - Coveralls

[oleonardolima]

@evanlinjin, I've started working on this one, on top of what you've suggested if you want to have a look.

I'm still thinking of ways to have better ergonomics on its usage, and not have the multiple deserialize_... methods.

[evanlinjin]

Thanks for the progress on this! I still need to have a proper look.

For now, I'm wondering whether we should just depend on the http crate for HTTP types. My argument is that hyper, ureq, reqwest all depend on it. minreq does not, but we can still convert from http types to minreq types, and I don't think we should promote it since it doesn't do H2.

[oleonardolima]

Thanks for the progress on this! I still need to have a proper look.

For now, I'm wondering whether we should just depend on the http crate for HTTP types. My argument is that hyper, ureq, reqwest all depend on it. minreq does not, but we can still convert from http types to minreq types, and I don't think we should promote it since it doesn't do H2.

Thanks! Sure, I'll update it to depend on the HTTP crate. It's a pretty slim dependency, and I don't see a problem with relying on it.

Agree, it's just a matter of implementing a From trait for the correspondent minreq (or any other http library) types.