Bug 3153: Prevent ICAP RESPMOD transactions getting stuck with the adapted body.

Bug 3153: Prevent ICAP RESPMOD transactions getting stuck with the adapted body.

Part 1.

  Server is expected to receive adapted response headers and then consume the
  adapted response body, if any. If the server receives the headers and then
  aborts, it must notify the ICAP side that nobody will consume the body.
  Otherwise, the ICAP transaction will fill the BodyPipe buffer and get stuck
  waiting for the consumer to free some space.

Part 2:

  This fix still leaves one potential race condition unhandled: The ICAP
  Initiatee disappears right after sending the adapted headers to the Server
  (because there is nothing else for that initiatee to do). After the
  noteAdaptationAnswer() call is scheduled by ICAP and before it is received by
  the Server job, there is no usable link between Server and ICAP.  There is no
  way for the Server to notify the ICAP transaction that the Server job is
  aborting during that time (and there is no Server job at all after it aborts,
  naturally).

  The solutions is to develop a custom AsyncCall which will call the
  expectNoConsumption() on the message pipe if the call cannot be dialed (i.e.,
  the message cannot be delivered to Server).