Sticky sessions scheduler

[krizhanovsky]

Depends on #235.

Actually foundation for Sticky cookie is application layer client identification, i.e. hash(client IP, User-Agent) identifies a 'virtual' client ('virtual' because there could be different clients behind the same proxy as well as couple of different browsers on the same device).

The identifier is used for scheduling the client requests to appropriate server (see Nginx sticky module and HAProxy sticky sessions) or for security issues. The second use case (HMAC key in particular) is the subject for #235. While the first application, sticky sessions scheduling, wasn't developed at all.

So hash scheduler must be extended such that it can use Tempesta sticky cookie value to decide which upstream server the message should be scheduled to. This will guarantee that HTTP session will be always processed by the same upstream server. No one current scheduler can guarantee HTTP sessions persistence, so Tempesta can break user experience.

Overall requests scheduling must have important property: if Tempesta receives first request within a new HTTP session, it must schedule the request, and correspondingly the whole session, to upstream using some other scheduling algorithm like round-robin or one of advanced load balancing algorithms. Actually hash scheduler using URI and Host values is also suitable for initial scheduling. See comment in tfw_http_req_cache_cb().

#235 introduces TfwHttpReq->TfwSession->TfwConnection:srv_conn. So if req->sess == NULL in tfw_http_req_cache_cb(), then tfw_sched_get_srv_conn() is called. Otherwise the function should check it whether it's alive first and just get the connection if so (likely). Otherwise it must get a new connection for server identified by req->sess->srv_conn->peer. The same scheduler, which originally scheduled the session must be used to get a new connection for the same server. To implement this logic lets rename sched_srv callback to sched_sg_conn and introduce the new callback TfwConnection *(*sched_srv_conn)(TfwMsg *msg, TfwServer *srv) which scheduled connection only from srv argument or return error if all the connections are dead. If sched_srv_conn() fails, then we should do one of two configurable options: print error log message and return 50x code to client or print warning error message and fallback to tfw_sched_get_srv_conn(). To implement sched_srv_conn() RR scheduler needs do very similar things as tfw_sched_rr_get_srv_conn(): find the server by pointer in the first loop and get a connection from it by the same residual. Hash scheduler can just ignore differ server in the loop like tfw_sched_hash_get_srv_conn().

Also don't forget to update README.

Also please implement appropriate unit test as for other schedulers.