MAJOR: raw_sock: extract raw_sock_to_buf() from raw_sock_read()

This is the start of the stream connection iterator which calls the
data-layer reader. This still looks a bit tricky but is OK. Splicing
is not handled at all at the moment.
MAJOR: raw_sock: temporarily disable splicing

It's too hard to convert splicing to connection+buf for now, so let's disable
it in order to make progress.
MINOR: stream-interface: add an rcv_buf callback to sock_ops

This one is to be used by the read I/O handlers.
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb()

The recv function is now generic and is usable to iterate any connection-to-buf
reading function from a stream interface. So let's move it to stream-interface.
MAJOR: connection: split the send call into connection and stream interface

Similar to what was done on the receive path, the data layer now provides
only an snd_buf() callback that is iterated over by the stream interface's
si_conn_send_loop() function.

The data layer now has no knowledge about channels nor stream interfaces.

The splice() code still need to be ported as it currently is disabled.
MAJOR: stream-interface: restore splicing mechanism

The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions
which in turn are called by the stream interface's recv and send callbacks.

The presence of the rcv_pipe/snd_pipe functions is used to attest support
for splicing at the data layer. It looks like the stream-interface's
SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy
for the pointers above.

It also appears that we call chk_snd() from the recv callback and then
try to call it again in update_conn(). It is very likely that this last
function will progressively slip into the recv/send callbacks in order
to avoid duplicate check code.

The code works right now with and without splicing. Only raw_sock provides
support for it and it is automatically selected when the various splice
options are set. However it looks like splice-auto doesn't enable it, which
possibly means that the streamer detection code does not work anymore, or
that it's only called at a time where it's too late to enable splicing (in
process_session).
MAJOR: stream-interface: make conn_notify_si() more robust

This function was relying on the result of file descriptor polling
which is inappropriate as it may be subject to race conditions during
handshakes. Make it more robust by relying solely on buffer activity.
MEDIUM: proxy-proto: don't use buffer flags in conn_si_send_proxy()

These ones should only be handled by the stream interface at the end
of the handshake now. Similarly a number of information are now taken
at the connection level rather than at the data level (eg: shutdown).

Fast polling updates have been used instead of slow ones since the
function is only called by the connection handler.
MAJOR: stream-interface: don't commit polling changes in every callback

It's more efficient to centralize polling changes, which is already done
in the connection handler. So now all I/O callbacks just change flags and
rely on the connection handler for the commit. The special case of the
send loop is handled by the chk_snd() function which does an update at
the end.
MAJOR: stream-interface: fix splice not to call chk_snd by itself

In recent splice fixes we made splice call chk_snd, but this was due
to inappropriate checks in conn_notify_si() which prevented the chk_snd()
call from being performed. Now that this has been fixed, remove this
duplicate code.
MEDIUM: stream-interface: don't remove WAIT_DATA when a handshake is in progress

This doesn't make sense and will only require that it's enabled again.
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops

Some parts of the sock_ops structure were only used by the stream
interface and have been moved into si_ops. Some of them were callbacks
to the stream interface from the connection and have been moved into
app_cp as they're the application seen from the connection (later,
health-checks will need to use them). The rest has moved to data_ops.

Normally at this point the connection could live without knowing about
stream interfaces at all.
REORG: buffers: split buffers into chunk,buffer,channel

Many parts of the channel definition still make use of the "buffer" word.
MAJOR: channel: remove the BF_OUT_EMPTY flag

This flag was very problematic because it was composite in that both changes
to the pipe or to the buffer had to cause this flag to be updated, which is
not always simple (eg: there may not even be a channel attached to a buffer
at all).

There were not that many users of this flags, mostly setters. So the flag got
replaced with a macro which reports whether the channel is empty or not, by
checking both the pipe and the buffer.

One part of the change is sensible : the flag was also part of BF_MASK_STATIC,
which is used by process_session() to rescan all analysers in case the flag's
status changes. At first glance, none of the analysers seems to change its
mind base on this flag when it is subject to change, so it seems fine not to
add variation checks here. Otherwise it's possible that checking the buffer's
output size is more useful than checking the flag's replacement.
REORG: buffer: move buffer_flush, b_adv and b_rew to buffer.h

These one now operate over real buffers, not channels anymore.
MINOR: channel: rename bi_full to channel_full as it checks the whole channel

Since the function takes care of the forward count and involves more than
buffer knowledge, rename it.
MINOR: buffer: provide a new buffer_full() function

This one only focuses on the input part of the buffer and is dedicated
to analysers.
MAJOR: channel: stop relying on BF_FULL to take action

This flag is quite complex to get right and updating it everywhere is a
major pain, especially since the buffer/channel split. This is the first
step of getting rid of it. Instead now it's dynamically computed whenever
needed.
MAJOR: channel: remove the BF_FULL flag

This is similar to the recent removal of BF_OUT_EMPTY. This flag was very
problematic because it relies on permanently changing information such as the
to_forward value, so it had to be updated upon every change to the buffers.
Previous patch already got rid of its users.

One part of the change is sensible : the flag was also part of BF_MASK_STATIC,
which is used by process_session() to rescan all analysers in case the flag's
status changes. At first glance, none of the analysers seems to change its
mind base on this flag when it is subject to change, so it seems fine not to
add variation checks here. Otherwise it's possible that checking the buffer's
input and output is more reliable than checking the flag's replacement.
REORG: channel: move buffer_{replace,insert_line}* to buffer.{c,h}

These functions do not depend on the channel flags anymore thus they're
much better suited to be used on plain buffers. Move them from channel
to buffer.