To support HTTP keep-alive correctly (and possibly pipelining), we
need to break the current model to support a 3-entity based model :

  - client-side session  ('scli' later)
  - server-side session  ('ssrv' later)
  - HTTP request         ('hreq' later)

Upon accept(), a new scli is created. It is bound to a specific client
and nothing else. It has a client-read time-out. If nothing is read
and the time-out is reached, then we must log an error (client read
timeout).

For each HTTP request we read on the client socket, we create an
hreq. If we have to create several hreqs, then we need to link them
so that the order is respected. They are all linked to the scli, so
that :

  - they know what buffers to use
  - they can find the previously used ssrv
  - if the client dies prematurely, we can destroy all hreqs

The current cli/srv time-outs will be partially moved to the hreq.

When the hreq considers it has got all the data, it can call
connect_server(). This last one either picks an existing ssrv, or
creates a new one. The ssrv must be linked to from the client so that
the next hreq can go to the same server by default. When the job is
done with the ssrv, this one can be queued as available if the session
is still valid. In any case, it must have an expiration time-out.

Implications :
--------------

1) HTTP keep-alive is easier to support :
  - read in scli, find a full request, create an hreq pointing to it
  - hreq creates (or reuses) an ssrv and sends the request
  - if ssrv is not closed, it can be reused for subsequent requests

2) HTTP pipelining is as easy :
  - scli reads *all* requests (with a possible max) and creates *all*
    hreqs.
  - Each hreq creates a new ssrv, or uses a free one attached to the scli.
  - ssrv's responses get merged in the hreq order.

3) HTTP requests merging is as easy :
  - new scli creates hreqs
  - hreqs don't find any existing ssrv in the scli, so looks for
    available ones in the global list.

4) Support for virtual servers should not be too hard :
  - scli reads the request.
  - depending on the Host: field, it creates a different hreq.
  => this just implies that in this case, the free ssrv list cannot be
     stored right into scli, but into scli->vhost. The vhost list is
     built from the listener's vhost list each time an unknown vhost
     is asked to the scli. Only the default one would be linked by
     default.

5) Multi-protocol support should not be too hard either :
  - scli either reads the request and emerges an hreq (or anything
    else in case of other protocol), or emerges an *req for other
    protocols (eg: smtp).
  => more generally, scli is protocol-specific. scli presented here is
     HTTP-specific, so are hreq and ssrv. Other types of sclis must be
     implemented for other protocols (eg: FTP will need couples).

6) Makes it easier to work with dynamic libraries, one per protocol,
   because the workflow is better detailed.