The connect(2) system call might return "connection ready"

The connect(2) system call might return "connection ready"
status even for a non-blocking file descriptor. The connection
itself can never be immediately ready in reality because of the
TCP handshake, but I am guessing that in some environments, the
TCP stack fakes/optimizes local connection readiness. We have
seen that for loopback sockets on FreeBSD 6.2, for example, but
the behavior is probably OS- or OS-configuration specific.

If connect(2) is immediately successful, comm module
immediately calls the callback. This means that the callback is
called while the same callback is being registered with comm.
ICAP does not allow this "re-entrance" and other code might not
deal well with it.

The change overwrites connect(2) result so that Squid does not
think that connect(2) was immediately successful. Instead of
calling the callback, Squid then schedules the connection
write-ability check.

The NativeAsyncCall development will fix this and remove the
need to overwrite connect(2) result because comm will always
call callbacks asynchronously.