Add some more metrics

[CHr15F0x]

This PR adds more counters. The vast majority of the PR content is tests for those, I tried to keep the production code delta as small as possible. Any ideas for more metrics will be put into a separate PR.

The number of commits is pretty big but I recommend going through the code on a per-file basis and skipping the tests first.

RPC counters

rpc_method_calls_total, uses a method label to distinguish between RPC methods

Sequencer counters

sequencer_requests_total
sequencer_requests_failed_total

EDIT: failure reasons are labels now
sequencer_requests_failed_starknet_total - requests failed due to StarkNet specific errors
sequencer_requests_failed_decode_total - requests failed due to deserialization errors
sequencer_requests_failed_rate_limited_total - requests failed due to rate limiting

1. All of the above use a method label to distinguish between request types (get_block, get_state_updates, etc.).
2. Additionally get_block, get_state_updates can use a tag label which is either latest or pending.
3. Failure counters can also be filtered using the reason label, with the following values:
   a. decode - requests failed due to deserialization errors
   b. starknet - requests failed due to StarkNet specific errors
   c. rate_limiting - requests failed due to rate limiting
4. The rationale for sequencer_requests_failed_decode_total decode is in the readme too, but long story short - once in a while these happen in bursts because of a cairo lang update and I imagine users would like to filter those out to avoid obfuscating the failures that happen on a daily basis.

Middleware

I think that wrapping reqwest into any existing or custom made middleware crate would be an overkill so I went with a simple macro and some simple wrappers. The macro frees developers from having to remember which and if all counters were registered. Additionally it produces a list of all the methods as & 'static str which increases the performance a bit, if we for example compare it to the rpc middleware passing non-static &str.

Testing

metrics uses a singleton Recorder, which is a bit problematic when trying to test metrics

TL;DR:

• if a test asserts the value of counter x, use RecorderGuard::lock(MyLocalMockRecorderInstance)
• other tests that touch counter x should use RecorderGuard::lock_as_noop()
• other tests that don't touch counter x don't care about RecorderGuard

I updated the RecorderGuard to decrease contention between tests that do not assert any counters. Unfortunately if one wishes to have repetitive results in a test which does assert some counter values, all other tests that could be triggering those counters concurrently have to use RecorderGuard::lock_as_noop().

[Mirko-von-Leipzig]

Meta: should we be testing these metrics? It adds a lot of extra code; is it worth it?

[CHr15F0x]

Meta:

1. My first thought was: nope, it's just counters.
2. My second thought was: implicitly or explicitly metrics are a public API so it's better to have some tests in case we refactor around the sequencer client, especially if a lot of labels come into play. It's fairly easy to break something there.

[kkovaacs]

LGTM other than that small naming nitpick.