Properly handle errors when sending HTTP error responses

[keshonok]

There's a set of tfw_http_send_XXX() functions in http.c module which send an HTTP error response, such as tfw_http_send_500(), etc. These functions return an error code if there's an error while sending an HTTP error response. However, these errors are never handled and there's no attempt to recover from these errors.

After the merge of #660 error responses are sent in proper seq order to a client. If a request results in an error response, and that error response could not be created and linked with the request, that leaves a "hole" in the seq queue. The hole forces Tempesta to stop sending responses to the client as it doesn't know that the response will never come. The connection with the client will hang around for some time until it's closed by the client or by Tempesta due to inactivity.

This situation needs to be handled properly. When it's known that there will be no response for a particular request, all prior responses should be sent out to the client as they are now, and then the connection should be closed by Tempesta.

A possible solution looks like this:

• tfw_http_send_XXX() functions handle all errors internally by calling tfw_http_resp_fwd() with a NULL response pointer. Therefore, these functions do not return an error code any more and are made void.
• tfw_http_resp_fwd() handles a NULL pointer to the response appropriately as described above.

This issue is NOT critical as it doesn't break Tempesta in any way. Also, it would occur only under severe memory pressure. Still, it's in everyone's best interests to close such connections as soon as possible.

[krizhanovsky]

Basically this is duplicate of #825 (Handling errors in constructing messages to clients) and was fixed in #839 . Sending unlucky responses before the error was considered as senseless, see discussion #839 (comment)