Added monitor rate-limiting functionality

[cmaglie]

This is an attempt to implement a rate-limiting functionality in the gRPC monitor service.

The rate limit subroutines are enabled when the config parameter recv_rate_limit_buffer is set to something >0. This will ensure backward compatibility with old clients.

When the rate limiter is enabled, the server will not send messages to the client unless the client acknowledges some slots.

• the client may acknowledge N slots by sending a message to the server with the recv_acknowledge field set to N
• the server can now send at most N messages, containing incoming data, back to the client
• the data field may contain incoming data that was buffered while there were no slots available, in this case, the amount of buffered data must be less than or equal to recv_rate_limit_buffer
• if the buffer is not consumed quickly enough, the excess of incoming data is dropped and the dropped field will report how many bytes have been lost.

an example of communication is:

--> { monitorConfig: { ......, recv_rate_limit_buffer: 10240 } }
--> { recv_acknowledge: 2 }
<-- { data: "...100 bytes...", dropped: 0 }
<-- { data: "...200 bytes...", dropped: 0 }

   ...the server here stops sending until the client acknowledges more slots...

--> { recv_acknowledge: 2 }    <--- A
<-- { data: "...10 bytes...", dropped: 0 }
--> { recv_acknowledge: 1 }    <--- B

   ...at this moment the server has still 2 sending slots, 1 remaining from A and another one from B...
   ...now let's suppose the server gets a burst of data...

<-- { data: "...5000 bytes...", dropped: 0 }
<-- { data: "...7000 bytes...", dropped: 0 }
   ...the client cannot keep up and answers with a bit of delay...
--> { recv_acknowledge: 2 }
<-- { data: "...10240 bytes...", dropped: 3000 }
   ...the server has answered with the maximum allowed buffer and signals that 3000 byes have been dropped...
--> { recv_acknowledge: 1 }

/cc @kittaakos

[kittaakos]

I have been using this CLI for a few days now; it works nicely. The gRPC API is also good. Thank you! +1 for merging it.