Author: Alex Rousskov <rousskov@measurement-factory.com>

Author: Alex Rousskov <rousskov@measurement-factory.com>
Author: Alexey Veselovsky <alexey.veselovsky@eykontech.com>
Author: Christos Tsantilas <chtsanti@users.sourceforge.net>
Bug 2055: Honor ICAP Max-Connections

This patch implements the phase 1 of the ICAP Max-Connections feature as it is
described in squid wiki:
  http://wiki.squid-cache.org/Features/ServiceOverload

The behaviour of the patch  can be configured using on_overload and max_conn
options of the icap_service configuration parameter. Squid can be configured
to do one of the following:
  - Block: send and HTTP error response to the subscriber
  - Bypass: ignore the "over-connected" ICAP service
  - Wait: wait (in a FIFO queue) for an ICAP connection slot
  - Force: proceed, ignoring the Max-Connections limit

Squid warns the first time the service become overloaded

For more information please visit the feature wiki page given above.

Technical informations:

The patch starts count a connections to the ICAP server as active when the
ModXact class receives an FD even if the fd is not really connected to the
server yet, and decrease the active connections to the server when the ModXact
object releases its fd connection.

If the Max-Connection limit is reached squid puts the request to a waiters list.
When one or more connections released squid schedules one or more waiters for
execution and remove them from waiters list.
To handle cases where a waiter gone/canceled before its execution the custom
dialer ConnWaiterDialer used.

The Options connections counted as active connections but are not limited by
the Max-Connections limit. An Option request will be executed even if the
maximum connections number is reached.

This is a Measurement Factory project