Make NODATACONN425 and NODATACONN421 return a 150 positive preliminary reply
before 425 or 421.

New NODATACONN150 returns 150 without further positive nor negative reply

Now NODATACONN doesn't reply anything at all.

Make NODATACONN custom commands apply to both active and passive FTP,
and ensure 425 and 421 are not returned unless data channel usage is
attempted.

Adjustments that make NODATACONN custom commands fully usable.

Try to be a little more descriptive about the effect of this flag,
rather than parroting what was said in the paragraph just above.

Some torture tests left FTP test server in an unresponsive state, resulting
in torture tests that actually completed following unexpected code paths.

Changes in this commit solely address this issue and some adjustments for
ftpserver.pl logging relative to data channel establishment and tear down.
Pending NODATACONN relative adjustments reserved for a further commit.

Ensure verification takes place with no server commands file.
Ignore verbose setting for running server precheck.
Tweak unresponsive server message, to allow detection by haxx.se scripts.

Fix called sub when checking TFTP server, and adjust message.

Extended server checks to others in addition to pingpong when torture testing.

NODATACONN421: applies only to active FTP mode, instructs server to not
establish data connection back to client and reply with FTP 421.

NODATACONN425: applies only to active FTP mode, instructs server to not
establish data connection back to client and reply with FTP 425.

NODATACONN: applies to both active and passive FTP modes, instructs server
to not establish nor accept a data channel and fool client into believing
that the data channel connection is possible.

Some polishing probably required.

Fix curl_multi_cleanup() segfault when using weird cleanup sequence.

This extends the fix from commit d7934b8b

When the multi state is changed within the multi_runsingle from DOING to
DO_MORE, we didn't immediately start the FTP state machine again. That
then left the FTP state in FTP_STOP. When curl_multi_fdset() was
subsequently called, the ftp_domore_getsock() function would return the
wrong fd info.

Reported by: Gokhan Sengun

5 more bug fixes, 4 additional contributors

When running torture tests, verify before each test case that required
pingpong servers which are supposed to be alive are actually responsive.
If found not responsive then restart them.

I created test 587 in commit 840eff44 but forgot to add the file to
the tarball. Added now.

This is using the verbatim 525 test code but it disables EPRT in the
server and this should work just as well anyway.

EPRT is now supported by default by the server. To disable it, use the
generic REPLY instruction in the <servercmd> tag. Test 116 now has it
disabled. All other existing active FTP port tests strip out the port
commands from the logs already so the change of the server isn't that
noticable.

As commit 5850cc48 clarifies, libcurl can deliver header lines that
are longer than CURL_MAX_WRITE_SIZE, only body data is limited to that
size. The curl tool has check (when built debug-enabled) that made the
wrong checks and this new test 1205 verifies that larger headers work.

Mention this maximum header size for the header callback cases

make sure the static build uses the static build option!

shoot, Dan Fandrich already had this pointed out...

Added pop3 username and password example as well as an explanation of
how path part of the URL is used under pop3.

Additionally have corrected a couple of typos.

Move curl_easy_perform source code geneartion out of curl_easy_perform's loop
for proper OOM handling and source code geneartion.

After a PORT has been issued, and the multi handle would switch to the
CURLM_STATE_DO_MORE state (which is unique for FTP), libcurl would
return the wrong fdset to wait for when curl_multi_fdset() is
called. The code would blindly assume that it was waiting for a connect
of the second connection, while that isn't true immediately after the
PORT command.

Also, the function multi.c:domore_getsock() was highly FTP-centric and
therefore ugly to keep in protocol-agnostic code. I solved this problem
by introducing a new function pointer in the Curl_handler struct called
domore_getsock() which is only called during the DOMORE state for
protocols that set that pointer.

The new ftp.c:ftp_domore_getsock() function now returns fdset info about
the control connection's command/response handling while such a state is
in use, and goes over to waiting for a writable second connection first
once the commands are done.

The original problem could be seen by running test 525 and checking the
time stamps in the FTP server log. I can verify that this fix at least
fixes this problem.

Bug: http://curl.haxx.se/mail/lib-2011-10/0250.html
Reported by: Gokhan Sengun

file_disconnect() free's resources for multi API

Additionally, improved error checking and logging.