Use multiple threads for grpc requests

[davidor]

The server uses several threads when attending HTTP requests, but only uses 1 when attending grpc requests. I have a WIP branch that fixes this, but it has another problem: both actix and tonic create N threads where N = number of cpus. Tonic seems to use only the threads it creates, but Actix uses also the ones created by Tonic. We'd need to either create just N threads in total and make both frameworks use them or make Actix use only the threads it creates. This only happens when using the async redis storage implementation.

WIP branch: https://github.com/3scale-labs/limitador/tree/run-grpc-reqs-in-multiple-threads

[alexsnaps]

We'd benefit most from this by having something along #69
While some parallelism while resolving the counters would be great, at least in an in-memory world, these threads would contend on the write locks protecting counters (they also do in the redis powered world, just further down the pipes and off our control to even be able to introduce parallelism)

[alexsnaps]

This crate here, by quickly glancing through the code, starts up a single tokio::runtime, used by both actix-web & tonic, then controlling how many worker actix-web should use and explicitly telling how many threads the tokio::runtime should create… Not arguing to use that crate, "just" sharing their approach…

[alexsnaps]

See #37

[alexsnaps]

This will require looking at where things are today first... These APIs changed a bit since, but we need to get a better handle on this and certainly prioritize the gRPC workload over the REST APIs one