[MEDIUM] do not add a cache-control: header when on non-cacheable responses

[MEDIUM] do not add a cache-control: header when on non-cacheable responses

I noticed that haproxy, with "cookie (...) nocache" option, always adds
"Cache-control: private" at the end of a header list received from this
server:

Cache-Control: no-cache
(...)
Set-Cookie: SERVERID=s6; path=/
Cache-control: private

or:

Set-Cookie: ASPSESSIONIDCSRCTSSB=HCCBGGACGBHDHMMKIOILPHNG; path=/
Cache-control: private
Set-Cookie: SERVERID=s5; path=/
Cache-control: private

It may be just redundant (two "Cache-control: private"), but sometimes it
may be quite confused as we may end with two different, more and less
restricted directions (no-cache & private) and even quite conflicting
directions (eg. public & private):

So, I added and rearranged a code, so now haproxy adds a "Cache-control:
private" header only when there is no the same (private) or more
restrictive (no-cache) one. It was done in three steps:

1. Use check_response_for_cacheability to check if response is
not cacheable. I simply moved this call before http_header_add_tail2.

2. Use TX_CACHEABLE (not TX_CACHE_COOK - apache <= 1.3.26) to check if we
need to add a Cache-control header. If we add it, clear TX_CACHEABLE and
TX_CACHE_COOK.

3. Check cacheability not only with PR_O_CHK_CACHE but also with
PR_O_COOK_NOC, so:

-                           unlikely(t->be->options & PR_O_CHK_CACHE))
+                           (t->be->options & (PR_O_CHK_CACHE|PR_O_COOK_NOC)))
                                txn->flags |= TX_CACHEABLE | TX_CACHE_COOK;

I removed this unlikely since I believe that now it is not so unlikely.

The patch is definitely not perfect, proxy should probably also remove
"Cache-control: public". Unfortunately, I do not know the code good enough
to do in myself, yet. ;)

Anyway, I think that even now, it should be very useful.