KNOWN_BUGS: remove five FTP related issues

- "FTP with CONNECT and slow server"

I believe this is not a problem these days.

- "FTP with NULs in URL parts"

The FTP protocol does not support them properly anyway.

- remove "FTP and empty path parts in the URL"

I don't think this has ever been reported as a real problem but was only
a hypothetical one.

- "Premature transfer end but healthy control channel"

This is not a bug, this is an optimization that *could* be performed but is
not an actual problem.

- "FTP without or slow 220 response"

Instead add to the documentation of the connect timeout that the
connection is considered complete at TCP/TLS/QUIC layer.

Closes #9979

docs/KNOWN_BUGS

@@ -73,14 +73,9 @@ problems may have been fixed or changed somewhat since this was written.
  6.13 Negotiate against Hadoop HDFS
 
  7. FTP
- 7.1 FTP without or slow 220 response
- 7.2 FTP with CONNECT and slow server
  7.3 FTP with NOBODY and FAILONERROR
  7.4 FTP with ACCT
  7.5 ASCII FTP
- 7.6 FTP with NULs in URL parts
- 7.7 FTP and empty path parts in the URL
- 7.8 Premature transfer end but healthy control channel
  7.9 Passive transfer tries only one IP address
  7.10 FTPS needs session reuse
  7.11 FTPS upload data loss with TLS 1.3
@@ -575,23 +570,6 @@ problems may have been fixed or changed somewhat since this was written.
 
 7. FTP
 
-7.1 FTP without or slow 220 response
-
- If a connection is made to an FTP server but the server then just never sends
- the 220 response or otherwise is dead slow, libcurl will not acknowledge the
- connection timeout during that phase but only the "real" timeout - which may
- surprise users as it is probably considered to be the connect phase to most
- people. Brought up (and is being misunderstood) in:
- https://curl.se/bug/view.cgi?id=856
-
-7.2 FTP with CONNECT and slow server
-
- When doing FTP over a socks proxy or CONNECT through HTTP proxy and the multi
- interface is used, libcurl will fail if the (passive) TCP connection for the
- data transfer is not more or less instant as the code does not properly wait
- for the connect to be confirmed. See test case 564 for a first shot at a test
- case.
-
 7.3 FTP with NOBODY and FAILONERROR
 
  It seems sensible to be able to use CURLOPT_NOBODY and CURLOPT_FAILONERROR
@@ -618,39 +596,6 @@ problems may have been fixed or changed somewhat since this was written.
 
  Since 7.15.4 at least line endings are converted.
 
-7.6 FTP with NULs in URL parts
-
- FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738 <user>,
- <password>, and <fpath> components, encoded as "%00". The problem is that
- curl_unescape does not detect this, but instead returns a shortened C string.
- From a strict FTP protocol standpoint, NUL is a valid character within RFC
- 959 <string>, so the way to handle this correctly in curl would be to use a
- data structure other than a plain C string, one that can handle embedded NUL
- characters. From a practical standpoint, most FTP servers would not
- meaningfully support NUL characters within RFC 959 <string>, anyway (e.g.,
- Unix pathnames may not contain NUL).
-
-7.7 FTP and empty path parts in the URL
-
- libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that
- such parts should be sent to the server as 'CWD ' (without an argument). The
- only exception to this rule, is that we knowingly break this if the empty
- part is first in the path, as then we use the double slashes to indicate that
- the user wants to reach the root dir (this exception SHALL remain even when
- this bug is fixed).
-
-7.8 Premature transfer end but healthy control channel
-
- When 'multi_done' is called before the transfer has been completed the normal
- way, it is considered a "premature" transfer end. In this situation, libcurl
- closes the connection assuming it does not know the state of the connection so
- it cannot be reused for subsequent requests.
-
- With FTP however, this is not necessarily true but there are a bunch of
- situations (listed in the ftp_done code) where it *could* keep the connection
- alive even in this situation - but the current code does not. Fixing this would
- allow libcurl to reuse FTP connections better.
-
 7.9 Passive transfer tries only one IP address
 
  When doing FTP operations through a proxy at localhost, the reported spotted

docs/cmdline-opts/connect-timeout.d

@@ -15,5 +15,8 @@ limits the connection phase, so if curl connects within the given period it
 will continue - if not it will exit.  Since version 7.32.0, this option
 accepts decimal values.
 
+The "connection phase" is considered complete when the requested TCP, TLS or
+QUIC handshakes are done.
+
 The decimal value needs to provided using a dot (.) as decimal separator - not
 the local version even if it might be using another separator.

docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT.3

@@ -43,6 +43,9 @@ In unix-like systems, this might cause signals to be used unless
 
 If both \fICURLOPT_CONNECTTIMEOUT(3)\fP and \fICURLOPT_CONNECTTIMEOUT_MS(3)\fP
 are set, the value set last will be used.
+
+The "connection phase" is considered complete when the requested TCP, TLS or
+QUIC handshakes are done.
 .SH DEFAULT
 300
 .SH PROTOCOLS

docs/libcurl/opts/CURLOPT_CONNECTTIMEOUT_MS.3

@@ -44,6 +44,9 @@ In unix-like systems, this might cause signals to be used unless
 
 If both \fICURLOPT_CONNECTTIMEOUT(3)\fP and \fICURLOPT_CONNECTTIMEOUT_MS(3)\fP
 are set, the value set last will be used.
+
+The "connection phase" is considered complete when the requested TCP, TLS or
+QUIC handshakes are done.
 .SH DEFAULT
 300000
 .SH PROTOCOLS