[refactor] #2144: redesign client's http workflow, expose internal api

[0x009922]

Description of the Change

Currently client is built on top of blocking synchronous HTTP client, which is not very flexible for different use cases.

To make it more flexible, I've split some of the APIs into 2 parts:

1. Preparing transaction/query/other HTTP request in terms of pure data
2. Handle related HTTP response for this request

I've moved the part of actual doing the request out of this. By the way, current main function are still using the default http implementation, but these parts are moved out from it.

It is done with a new trait - RequestBuilder. I've added several functions to the Client:

• prepare_query_request(query, pagination), that returns a tuple with a provided RequestBuilder and a special response handler.
• prepare_transaction_request(tx), same as for queries, but also returns a hash of a transaction.
• prepare_status_request(), same as above, but simpler.

There are also 3 new structs - QueryResponseHandler, TransactionResponseHandler and StatusResponseHandler. All of them encapsulates the logic of handling an HTTP-response in a correct way.

I haven't touched WebSocket-based logic and some other complex utilities that rely on default HTTP client yet. Anyway it should be refactored as well.

Also I've refactored the http internal module itself.

Issue

Resolves #2144

Benefits

• Possibility to use iroha_client with custom HTTP transport, even async. Only for queries, transactions and status for now.
• Usage of trait RequestBuilder allows to build requests in an efficient way. It would be less efficient if build it via callbacks or by returning the exact request structure.
• Client is still responsible to handle http response
• You don't need to import anything to handle response, and currently "responders" are a zero-cost abstraction
• Existing client API hasn't been changed, but has been extended.

Possible Drawbacks

• Headers are still HashMap<String, String>, which can be optimized in scope of RequestBuilder trate.
• Response handlers expect Response structure from the http crate. It may be unefficient if custom http implementation returns some other response and user has to transform it first. Maybe it is better to replace Response with some trait.

Usage Examples or Tests

Existing client methods now uses the same API, but with default HTTP client. See how they now work.