Add prometheus support

[Guilospanck]

Closes #166 .

This PR adds support for Prometheus, while giving an example of its integration with Grafana as well.

Summary

• Adds new (optional) cargo project named metrics that holds information about the Prometheus metrics and that can be used in a singleton way;
• Adds docker-compose.yml file to examplify how to deploy floresta+prometheus+grafana infra;
• Adds two example metrics: system memory used (GB) and current block height.

Example of added metrics in Grafana:

Testing

Be sure to have Docker Compose

Run docker-compose up -d --build, wait for it to start all services and then go to http://localhost:3000/, where you can log into Grafana using the given credentials found in the docker-compose.yml file.

There, you can go to Dashboards on the left, add New, select Prometheus as the data source (should be pre-selected) and then choose one of the metrics, the data visualization type and run the queries to see it in action.

Improvements

I'm not too familiar with the codebase, therefore adding metrics to the best places would be better done by someone who has.

During the tests with the deployment of the infra with docker-compose.yml noticed that there is something off going on with the system, probably related to this, that it was driving the CPU usage over 100% and the memory at around 8GB, maintaining this last one during the initial block downloading at least.

The high CPU and memory usage would go off the roofs around this part.

[Davidson-Souza]

This is so cool! I'm using a grafana dashboard with this, and it looks sick! Thanks for working on this.

During the tests with the deployment of the infra with docker-compose.yml noticed that there is something off going on with the system, probably related to #294, that it was driving the CPU usage over 100% and the memory at around 8GB, maintaining this last one during the initial block downloading at least (that's why the docker compose has this configuration

I had the same thing happening here, it seems worse on docker than native. I've narrowed that down to sled, because the spikes happen exactly when sled flushes. Right after downloading all headers, we do one flush. On my machine, florestad inside docker was using 12GB of RAM 🤯 . This is why I've started #251. After this PR, we use less than 1GB of RAM, even for IBD (The [app](https://github.com/jvsena42/floresta_app] uses #251, otherwise android would kill it).

For this PR, could we get prometheus as an (optional) feature for forestad?

[Guilospanck]

@Davidson-Souza Done ✅ Lemme know if this is what you had in mind.
And the improvement you have for the #251 would be awesome for the project 💯

[Davidson-Souza]

Lemme know if this is what you had in mind.

Yes! Looks great!

Just one small thing I've noticed: I'm getting some unused imports warning if building lib mode

 --> florestad/src/florestad.rs:6:5
  |
6 | use std::net::Ipv4Addr;
  |     ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unused import: `tokio::time::Duration`
  --> florestad/src/florestad.rs:50:5
   |
50 | use tokio::time::Duration;
   |     ^^^^^^^^^^^^^^^^^^^^^

warning: unused import: `self`
  --> florestad/src/florestad.rs:51:19
   |
51 | use tokio::time::{self};
   |                   ^^^^

[Guilospanck]

Thanks for spotting that @Davidson-Souza !
I created this other PR #319 because I find myself forgetting about this kind of stuff every time.

[Davidson-Souza]

ACK 9e3db25