Implement TLS support (aka explicit ftps).  This is done by using a
different URL scheme, ftps, so that it is only used if explicitly
specified.

Although the protocol allows transparently upgrading a normal
connection to a secure one, there are several problems with this.
FEAT is needed to determine support for it but some servers do not allow
this before login.  Some servers are configured to allow AUTH TLS but
have firewalls that block data connections because they can't inspect
the traffic.  Servers may disallow TLS on the data connection, making it
unclear to the user how secure the connection is.  Finally, there may be
verification errors which need to be presented to the user, and these
are unexpected because they did not choose to use ftps.

Making secure ftp opt-in as a separate URL scheme side-steps most of
these issues as well as ensuring there are no regressions for normal
ftp.  When using ftps, we assume that the server implements AUTH TLS so
the connection is secured before login. It is also assumed that TLS for
data connections is allowed, so both control and data connection are
secure before any information is transferred.
Verification errors are presented during mounting.  If the identity
changes on subsequent reconnections, the connection is aborted.
While presenting verification errors to the user in this way is perhaps
not the best way of handling security, it is fairly standard.

The implementation has been successfully tested on vsftpd, ProFTPD,
Pure-FTPd, IIS, and FileZilla Server.

Based on a patch by Benjamin Otte.

https://bugzilla.gnome.org/show_bug.cgi?id=526582