feat: readiness

[simone-sanfratello]

note: to be rebased after #180

The PR aims to replace the current readiness logic. Current readiness logic is based on the fact the 3rd party storage such as AWS Dynamo and S3 are able to respond. This is good for low traffic service, but not good enough for the intense traffic of the bitswap-peer service.

The proposed readiness logic is going to consider:

• amount of active connections
• pending request blocks
• event loop utilization (ELU)

Where active connections and and pending request blocks are hard limits got from production metrics, ELU is a index of the node inner process "busyness", so when one of them pass the limit, we can consider the single instance "busy" and stop to send it more request, until it solves the pending load. Note the ELU is more significant than memory and cpu usage - we're going to add them to the readiness logic in the future, if needed.

Open question: should be consider Dynamo and S3 access for readiness?

What we want to really avoid is this situation, where the service is busy responding (for ~10 minutes at ~15.00) but it still receive requests

More info: https://www.nearform.com/blog/event-loop-utilization-with-hpa/

Also note, the next step for bitswap scalability will be to implement on the k8s load balancer to scale services based on custom parameters, that will be the same (active connections, pending blocks, ELU) exposed on the /load endpoint