[Tests] Functional tests for JS Challenge

[vankoven]

Need to implement functional tests for #536 . Pay attention to #536 (comment) : not all the requests may be challenged.
See https://github.com/tempesta-tech/tempesta/blob/master/tempesta_fw/http.c#L2140-L2154 for more information how TempestaFW responds to sticky cookie and JS challenge violations.

The test must implement following cases:

Client side:

• legitimate client: send request with cookie set just in time
• legitimate client: send request at any time during delay_limit
• legitimate client with pipelined requests. First request can be challenged, others - not (e.g. images). Agent send all requests pipelined (not allowed by standard but a good testcase). All requests must be responded to keep response-request pairing consistent on client side, so client must be able to get the resource in the same connection after it's authorised. After discussion we decide, that we should answer with redirect for all pipelined requests.
• attacker: bomb requests with cookies. Client mustn't be authorized until cookie_timestamp + delay_min + cookie_timestamp % delay_range . Keep in mind Sessions rate limit #598: with that improvement client must be blocked and never be authorised. Tempesta must close connection (or respond with error) for every request from that client. After discussion we decide that we should close connection after first request. Response should be sent only for first request.
• attacker: send requests after delay_limit elapsed. Same expectations as above. delay_limit was removed
• JS is disabled of the client This is invalid case. JS MUST be enabled for client.
• Legitimate client has an outdated cookie before accessing the server.

Tempesta Side:

• All variants (3) of redirect status code: 302, 503 and any other custom code
• User defined JS challenge template at non-default location.
• Per-Vhost JS challenge configuration We have per-vhost tests for the Sticky directive in the sessions.test_cookies

JS Challenge code tests:

• Client has only one cookie: sticky cookie from Tempesta
• Client has many cookies, and sticky cookie from Tempesta can be found at any place: beginning, the middle or the end of cookies
• Client has many cookies, some of them has parameters The Cookie header does not have parameters.
• Client has many cookies and name of Tempesta's sticky cookies is a substring of other cookies names or parameters

Session identification:

• Client opens a new session, which is not exist: JS challenge is performed
• Client opens an already present session: JS challenge is skipped
• Client opens a session which is valid but already removed from Tempesta: Full restart of JS challenge: client receives new cookie and perform a fresh JS challenge.

[krizhanovsky]

#880 is duplicate for the issue, its original requirements:

Please develop a functional test for the #536 . A case for a web site with an index.html referencing non-challengable <img> resource must be checked: we must not challenge the image request, the request must be blocked by the module if it doesn't contain the cookie or contain invalid cookie and normally passed if the check was satisfied. Check the timeouts and try to wait bit less than the required delay. Please very carefully follow and test various scenarios from the algorithm described in the original issue. Think about possible protection evasion methods.

The change also affects HTTP sessions handling, so please reimplement t/unit/test_http_sticky.c as a functional test and remove the original unit test. Such kind of tests make a lot of headache in support.