BUG/MEDIUM: http: adjust close mode when switching to backend

Commit 179085c ("MEDIUM: http: move Connection header processing earlier")
introduced a regression : the backend's HTTP mode is not considered anymore
when setting the session's HTTP mode, because wait_for_request() is only
called once, when the frontend receives the request (or when the frontend
is in TCP mode, when the backend receives the request).

The net effect is that in some situations when the frontend and the backend
do not work in the same mode (eg: keep-alive vs close), the backend's mode
is ignored.

This patch moves all that processing to a dedicated function, which is
called from the original place, as well as from session_set_backend()
when switching from an HTTP frontend to an HTTP backend in different
modes.

This fix must be backported to 1.5.
(cherry picked from commit 4e21ff9244aefa56bcf0793a9e07edba2c3c1960)
BUG/MINOR: config: don't propagate process binding on fatal errors.

propagate_processes() must not be called with unresolved proxies, but
nothing prevents it from being called in check_config_validity(). The
resulting effect is that an unresolved proxy can cause a recursion
loop if called in such a situation, ending with a segfault after the
fatal error report. There's no side effect beyond this.

This patch refrains from calling the function when any error was met.

This bug also affects 1.5, it should be backported.
(cherry picked from commit acbe8ab38a638a076f8cf9fe2635db0e729d6a1f)
BUG/MEDIUM: check: rule-less tcp-check must detect connect failures

When "option tcp-check" is specified without any tcp-check rules, the
documentation says that it's the same as the default check method. But
the code path is a bit different, and we used to consider that since
the end of rules was reached, the check is always successful regardless
of the connection status.

This patch reorganizes the error detection, and considers the special
case where there's no tcp-check rule as a real L4 check. It also avoids
dereferencing the rule list head as a rule by itself.

While fixing this bug, another one related to the output messages'
accuracy was noticed, it will be fixed in a separate commit and is
much less important.

This bug is also present in 1.5, so this fix must be backported.
(cherry picked from commit ef953953e7f33c6a72c432fce8d47c2d84c69512)
BUG/MINOR: tcp-check: report the correct failed step in the status

The step number was reported by checking only last_started_step, which
was not set in case of error during the initial connection phase, and
caused "step 1" to be returned with an invalid check type (typically
SEND). So now we first verify that a test was started before returning
this.

In addition to this, the indication of the test type was taken from
current_step instead of last_started_step, so the error description
was matching the next action instead of the one reported in the step
ID. Thus we could get the confusing "step 1 (send)" report below :

      tcp-check connect
      tcp-check send foo

In order to ease debugging, when the port number is known for a connect,
it is indicated in the error report.

Note that this only affects asynchronous error messages, synchronous ones
are correct.

This fix must be backported to 1.5.
(cherry picked from commit 213c6785614d0228d7e96e982e5189e1d0777059)
BUG/MINOR: config: don't propagate process binding for dynamic use_backend

A segfault was reported with the introduction of the propagate_processes()
function. It was caused when a use_backend rule was declared with a dynamic
name, using a log-format string. The backend is not resolved during the
configuration, which lead to the segfault.

The patch prevents the process binding propagation for such dynamic rules, it
should also be backported to 1.5.
(cherry picked from commit 51639696e0a112ea3612e905a5722ad912b3869f)
DOC: Address issue where documentation is excluded due to a gitignore rule.

(cherry picked from commit fbc4e77321f6e92b7af658ce8257b6231c6ebac9)
DOC: indicate that weight zero is reported as DRAIN

It's not the same state but reported as such.
(cherry picked from commit c5af3a6d15358fa8b5be6151239862efde4c36f7)
[RELEASE] Released version 1.5.5

Released version 1.5.5 with the following main changes :
    - DOC: Address issue where documentation is excluded due to a gitignore rule.
    - MEDIUM: Improve signal handling in systemd wrapper.
    - BUG/MINOR: config: don't propagate process binding for dynamic use_backend
    - MINOR: Also accept SIGHUP/SIGTERM in systemd-wrapper
    - DOC: clearly state that the "show sess" output format is not fixed
    - MINOR: stats: fix minor typo fix in stats_dump_errors_to_buffer()
    - DOC: indicate in the doc that track-sc* can wait if data are missing
    - MEDIUM: http: enable header manipulation for 101 responses
    - BUG/MEDIUM: config: propagate frontend to backend process binding again.
    - MEDIUM: config: properly propagate process binding between proxies
    - MEDIUM: config: make the frontends automatically bind to the listeners' processes
    - MEDIUM: config: compute the exact bind-process before listener's maxaccept
    - MEDIUM: config: only warn if stats are attached to multi-process bind directives
    - MEDIUM: config: report it when tcp-request rules are misplaced
    - MINOR: config: detect the case where a tcp-request content rule has no inspect-delay
    - MEDIUM: systemd-wrapper: support multiple executable versions and names
    - BUG/MEDIUM: remove debugging code from systemd-wrapper
    - BUG/MEDIUM: http: adjust close mode when switching to backend
    - BUG/MINOR: config: don't propagate process binding on fatal errors.
    - BUG/MEDIUM: check: rule-less tcp-check must detect connect failures
    - BUG/MINOR: tcp-check: report the correct failed step in the status
    - DOC: indicate that weight zero is reported as DRAIN
BUG/MEDIUM: systemd: set KillMode to 'mixed'

By default systemd will send SIGTERM to all processes in the service's
control group. In our case, this includes the wrapper, the master
process and all worker processes.

Since commit c54bdd2a the wrapper actually catches SIGTERM and survives
to see the master process getting killed by systemd and regard this as
an error, placing the unit in a failed state during "systemctl stop".

Since the wrapper now handles SIGTERM by itself, we switch the kill mode
to 'mixed', which means that systemd will deliver the initial SIGTERM to
the wrapper only, and if the actual haproxy processes don't exit after a
given amount of time (default: 90s), a SIGKILL is sent to all remaining
processes in the control group. See systemd.kill(5) for more
information.

This should also be backported to 1.5.
(cherry picked from commit 74f016985ab1fa7a6a5afa301d982e77eba9c96a)
BUG/MEDIUM: config: avoid skipping disabled proxies

Paul Taylor and Bryan Talbot found that after commit 419ead8 ("MEDIUM:
config: compute the exact bind-process before listener's maxaccept"),
a backend marked "disabled" would cause the next backend to be skipped
and if it was the last one it would cause a segfault.

The reason is that the commit above changed the "while" loop for a "for"
loop but a "continue" statement still incrementing the current proxy was
left in the code for disabled proxies, causing the next one to be skipped
as well and the last one to try to dereference NULL when seeking ->next.

The quick workaround consists in not disabling backends, or adding an
empty dummy one after a disabled section.

This fix must be backported to 1.5.
(cherry picked from commit 06cc905813f1858c0606b44d1e271bd0b6a25224)