HTTP requests fair scheduling

[krizhanovsky]

Currently we pick a server connection for a request scheduling in tfw_http_msg_process(), making several calls, but technically if a client send us many pipelined requests like:

GET / HTTP/1.1\r\n
Host: foo\r\n

GET / HTTP/1.1\r\n
Host: foo\r\n
....

, then current softirq will spin in a loop processing the ingress requests and sending them to a backend server. It's worth mentioning that there is GRO segementation, i.e. we can have up to 64KB of ingress requests processed in once.

Having that we might run in small dedicated or virtual environments with just a few CPUs and correspondingly softirqs, massively pipelining clients can hurt or fully block other clients' progress.

We have to introduce some fair processing of ingress requests. There is even no sense to parse HTTP request if currently this is not the client turn to send a request. Probably some timing wheel can be used for the fair scheduling. Maybe current ring-buffer queue can be used for this... Probably should be done together with #687 since current queue lists can be replaced with a new scheduling data structure, preferablu lock-free. Also somewhat linked with #488: it could has sense to manage QoS not only on receive TCP buffer, but also by scheduling more or less requests to a backend.

[krizhanovsky]

With HTTP/2 many streams in the same TCP connection lead to the same scenario