Uniform API for custom headers between clients

[lexnv]

Jsonrpsee allows users to set custom headers during the WS handshake (for the ws-clients).

This PR extends the ability to add custom headers for the HTTP clients.

The PR introduces a uniform API for the client builders, relying on http::HeaderMap

pub fn set_headers(mut self, headers: http::HeaderMap) -> Self

that behaves as follows:

• ws-client: Custom headers are used only during the handshake
• http-client: Custom headers are submitted with every request

One advantage is that the ws-client and http-client have a uniform API, used for caching or any custom user operations, extending jsonrpsee beyond the realm of the Substrate.
One disadvantage is that ws-client uses soketto that internally requires an httparse::Header object, which leads to conversion from http::HeaderMap only if present.

Next Steps

• Write documentation to illustrate differences between ws/http clients

Closes #809.

[niklasad1]

LGTM,

I like this and I have created this PR https://github.com/paritytech/soketto/pull/60/files which changes soketto to use HeaderMap but I need to benchmark it.

Especially for the client is makes sense as to have this verification as invalid HTTP headers can't be created.

httparse is really intended for parsing HTTP headers not create them :P

[jsdw]

Liking the standardisation! Any idea what the performance impact of this change is?

[niklasad1]

For the websocket client is should "only" impact the connection speed and we have no benchmarks for that....

On the other hand for the HTTP client the headers are "cloned" for each call which should visible on the benchmarks if we enabled "some custom headers".

[lexnv]

The results of running the benchmarks surprisingly improved performance for some scenarios.
However, there are some cases where performance was below the accepted threshold of the criterion.

Scenario	Run 1	Run 2
async/http_batch_requests/memory_intense/50	-6.5777%	+54.263%
async/ws_batch_requests/memory_intense/100	+5.9838%	+66.996%

The test runs were performed a few hours apart, without changing the commit head (this one).
The difference between the test runs suggests that my machine is not quite reliable. Went from a negative difference (improvement) to positive (regression) with more than 55% between runs.

A few other outliers

# Regressions
async/http_batch_requests/fast_call/5      +7.2570%
async/http_batch_requests/fast_call/100  +16.523%
sync/ws_concurrent_conn_calls/4             +6.3084%

# Improvements
async/ws_concurrent_conn_calls/8                     -4.6004%
async/ws_concurrent_conn_calls/2                     -4.7548%
async/http_concurrent_conn_calls/fast_call/2     -15.231%

That being said, I think we'll get a more reliable read of the benchmarks running the nightly CI.

[niklasad1]

The batch benches are really "random", so nothing to with your PR but probably worth to investigate why that is.

The HTTP requests could be faster as the actual request headers are "cached" and cloned on each request which wasn't the case before.

However, it would be good to add two additional benches:

1. WS connection time with different size of headers
2. HTTP calls with different size of headers

Feel free to merge this one but I don't think the current benches really matter that much for this PR.