BUG/MAJOR: buffers: make the buffer_slow_realign() function respect output data

BUG/MAJOR: buffers: make the buffer_slow_realign() function respect output data

The function buffer_slow_realign() was initially designed for requests
only and did not consider pending outgoing data. This causes a problem
when called on responses where data remain in the buffer, which may
happen with pipelined requests when the client is slow to read data.

The user-visible effect is that if less than <maxrewrite> bytes are
present in the buffer from a previous response and these bytes cross
the <maxrewrite> boundary close to the end of the buffer, then a new
response will cause a realign and will destroy these pending data and
move the pointer to what's believed to contain pending output data.
Thus the client receives the crap that lies in the buffer instead of
the original output bytes.

This new implementation now properly realigns everything including the
outgoing data which are moved to the end of the buffer while the input
data are moved to the beginning.

This implementation still uses a buffer-to-buffer copy which is not
optimal in terms of performance and which should be replaced by a
buffer switch later.

Prior to this patch, the following script would return different hashes
on each round when run from a 100 Mbps-connected machine :

  i=0
  while usleep 100000; do
    echo round $((i++))
    set -- $(nc6 0 8001 < 1kreq5k.txt | grep -v '^[0-9A-Z]' | md5sum)
    if [ "$1" != "3861afbb6566cd48740ce01edc426020" ]; then echo $1;break;fi
  done

The file contains 1000 times this request with "Connection: close" on the
last one :

  GET /?s=5k&R=1 HTTP/1.1

The config is very simple :

  global
        tune.bufsize 16384
        tune.maxrewrite 8192

  defaults
        mode http
        timeout client 10s
        timeout server 5s
        timeout connect 3s

  listen px
        bind :8001
        option http-server-close
        server s1 127.0.0.1:8000

And httpterm-1.7.2 is used as the server on port 8000.

After the fix, 1 million requests were sent and all returned the same
contents.

Many thanks to Charlie Smurthwaite of atechmedia.com for his precious
help on this issue, which would not have been diagnosed without his
very detailed traces and numerous tests.

The patch must be backported to 1.5 which is where the bug was introduced.
(cherry picked from commit 27187ab56a2f1104818c2f21c5139c1edd8b838f)