Properly store and build HTTP headers

[krizhanovsky]

Currently we copy HTTP server headers from TDB. We do this to be able to adjust them in tfw_http_adjust_resp(). However, with #409 in mind and that we should store responses with already calculated Via and Server headers instead of adjusting them for each serviced request. So in general there should be two tfw_http_adjust_resp() versions: one of them is executed when response is received and cached and the second one does client specific adjustments.

So after the changes we can directly send headers and status line from TDB as we do this for response body.

We shall form only one skb for small responses avoiding multiple skb fragments. However, paged fragment seems applicable and are the way how the issue should be implemented.

[vankoven]

Keeping in mind implementation of #409: #650. While setting right value for Server header hop-by-hop mark for that header should be removed. This should be done before removing hop-by-hop headers

[krizhanovsky]

The issue didn't pay attention to TLS: we have to copy data for encryption, i.e. we can not directly put an skb data to a socket any more. The only thing which we can do is to optimize copying and fragmentation in tfw_http_adjust_resp() - the subject for #1103.

[krizhanovsky]

We do need to copy cached HTTP response, however, HTTP headers are copied twice now - in tfw_cache_build_resp() and tfw_tls_encrypt(). There are also problems with HTTP headers adjustments (#1103) between the copies. Thus, to behave more efficiently in TLS and HTTP/2 we should do following:

1. Currently we store HTTP responses in our own representation, e.g. TfwCStr is used to write string data with prefix length. This is very close to HPACK. So to minimize memory footprint and speedup HTTP/2 cache service, we should store HTTP responses in HPACK format. HTTP static table should only be used for generic representation.

2. Do not spend processing resources on Huffman dynamic encoding - just send HTTP responses from cache as is.

3. Invocation and the calling loop for tfw_cache_build_resp_hdr() in tfw_cache_build_resp() should be integrated with tfw_http_adjust_resp() (via callback for example) to generate all required HTTP/1 or HTTP/2 headers in one shot with only one memory allocation. Tightly linked with Optimizer for HTTP messages adjustment #1103.

4. Original requirement that we should store responses with already calculated Via and Server headers, and probably some others, instead of adjusting them for each serviced request still makes sense. The two tfw_http_adjust_resp() versions must be integrated with Optimizer for HTTP messages adjustment #1103 and the point above.

5. Since all the copying is done in tfw_cache_build_resp() the skbs must not have SKBTX_SHARED_FRAG flag. Also it seems tfw_tls_encrypt() can be optimized to call skb_to_sgvec() only for sgt and ttls_encrypt() may accept sgt instead of sgt_out.

This issue invalidates #391 .10. We're not able to use cache data in zero-copy fashion any more (with widespread TLS), so we have to traverse TDB entries for copying any time.TfwHttpResp is allocated in the same TfwPool entry as TfwHttpHdrTbl and stores pointers to actual data, so it also can not be just copied.