Ftp gateway: initial implementation.

The first client command must be USER with
<username>@<hostname>[:<port>] parameter.  Origin server connection is
bound to client connection.  After origin server connection is
established, it cannot be changed, i.e. client cannot connect to
another origin server.  Once server or client connection is closed,
the other side should be closed as well.

Only passive mode is supported on both client and server side.  IPv6
(RFC 2428 EPSV command) is not supported.

Implemented data transfer commands: RETR, LIST, NLST.  Data push
commands (STOR, APPE) are not implemented.

Many rough edges: aborts/timeouts/error handling, logging and more.
Ftp gateway: remove ClientHttpRequest::flags::ftp.

Use ConnStateData::isFtp instead.
Ftp gateway: fix handling of internal errors (e.g. from ICAP).

Before the change, HTTP replies with internal errors resulted in
segfaults.

Use distinct HTTP status codes for regular FTP replies on control
channel and for data transfers.  Regular FTP replies use 204 No
Content status code now.  FTP data transfer replies use 200 Ok as
before.
FTP gateway: fix segfault processReplyBody() when adaptation is enabled.

If adaptation is enabled, processReplyBody() may be called before
maybeReadVirginBody() when data.readBuf is not yet initialized.
FTP gateway: process FTP request asynchronously.

Before the change, FTP request processing was done right after
parsing.  This could result in data transfer request failure because
data connection accept callback was already scheduled but not fired
yet.  The patch makes FTP request processing asynchronous to fix this
race.
FTP gateway: upload support.

The patch adds support for FTP upload commands: STOR, APPE and STOU.
FTP gateway: fix upload freezing for large files.
FTP gateway: fix segfault during large file download.
FTP gateway: interception mode for ftp_port.
FTP gateway: web browsers compatibility fix.

Do not forward server greeting to client as a preliminary reply
because it may confuse web browsers.
Fixed address handling for PASV responses in interception cases.

Added debugging, comments.
Initial support for active FTP downloads via the FTP PORT command.

Squid accepts PORT command on the client side, but still uses passive transfer
on the server side. The PORT command response is not sent to the client until
the server-side PASV command succeeds. The data connection to the client is
not opened until Squid receives the RETR command from the client.

Squid requires either PORT or PASV command before data transfers. RFC 959 says
PORT is optional because default ports can be used. 

RFC 959 also seems to imply that Squid should originate active connections to
client from port 20.  The code to do that is commented out for now because it
would prevent support for concurrent data connections. The code configuring
this outgoing (but to-client) connection may need more work as we do a lot
more for outgoing to-server connections.

Active data upload has not been tested.
Use the _last_ @ to find the end of the FTP USER name
(and the start of the FTP server host name).
Fixed client_side.cc "context->socketState() == STREAM_COMPLETE" assertion
on client-aborted downloads.

Improved debugging.
Provide user with more details on forwarding/adaptation errors.

In addition to "421 Service Unavailable", print %c and %E errorpage info.
Needs more work to make FTP error messages configurable, just like they are
for HTTP.
When writing FTP errors to the client, omit ERR_NONE error name.
Render adaptation X-Response-Info and X-Response-Desc meta values in FTP errors
caused by adaptation (e.g., an ICAP service blocking an FTP command)

Requires adaptation history to be enabled, which can be achieved by logging
adaptation meta headers to access log (%adapt::<last_h) or setting
adaptation_masterx_shared_names in squid.conf

Long term, the contents of the error message should be configurable via
error message templates (which may include these semi-standard meta headers).
Avoid segfaults when RETR is not preceded by PORT or PASV.

Polished code.
Avoid some unnecessary FTP control connection closures; polished FTP failure 
code.

Do not close FTP server control connection just because FTP response
adaptation is done. We still close FTP connections if we are receiving the
virgin response (because we have no place to store it), but if we are done
receiving, there is no need to terminate FTP server connections. The former
happens when an ICAP service responds before receiving the entire virgin FTP
response. The latter, when the ICAP service responds after the FTP data
connection is closed but before the control 226 response comes in.

Do not close FTP client control connection just because we served a non-OK
control response. The client may still send us commands if our ClientStream is
still in a good state. This may happen when an FTP download is prohibited by
an adaptation service via an HTTP 403 Forbidden response, for example.

Avoid STORE_PENDING assertion in FwdState::reforward() due to double
forwarding completion by FtpGatewayServer. Similar code exists in regular FTP
server and is needed for gatewaying as well because FTP may keep open (and
expect a control response on) the control connection after adaptation is
completed, creating two avenues for a FwdState::complete() call.

Ftp::ServerStateData::failed() should always call FwdState::fail(), to supply
forwarding code with ErrorState details. And we should not create the error
HttpReply in the FTP code. FwdState code does that, probably because it may
reforward the request and, hence, bypass some errors. For now, FTP gateway
code still creates an HttpReply (in addition to calling FwdState::fail) to be
able to supply custom gatewaying error information. Eventually, that should be
done via custom ErrorState object (that will later create an appropriate
HttpReply when/if needed).

Added debugging.
Do not close FTP gw server control connection on more server-unrelated errors.

FtpGatewayServer now forgets about its control connection to the server once
it is done communicating with that server. This allows us to preserve that
connection on FTP transaction errors (e.g., forbidden responses or broken
ICAP servers) that are not related to the server communication and can be
ignored as far as the next FTP gatewayed transaction is concerned.

Removed special DONE state because it is now identical to doneWithServer().

Fixed ServerChannel::forget() to prevent subsequent forgotten connection
closure.