fix(ftp): handle empty port parameter and ensure strictly numeric ports

[bahman026]

Summary

Creating an FTP/FTPS external storage with an empty Port field ends in an HTTP 500.

FTP::__construct() read the port like this:

$this->port = $parameters['port'] ?? 21;

?? only substitutes null or a missing key. The external storage settings submit an
empty string when the field is left blank, so "" was assigned to $this->port and
passed on to FtpConnection::__construct(bool $secure, string $hostname, int $port, ...).
PHP rejects a non-numeric string for an int parameter, so the request died with a
TypeError:

OCA\Files_External\Lib\Storage\FtpConnection::__construct(): Argument #3 ($port)
must be of type int, string given, called in apps/files_external/lib/Lib/Storage/FTP.php

A numeric string such as "2121" is coerced normally, so explicitly configured ports
were never affected — only an empty (or otherwise non-numeric) value.

Two details make the failure more confusing for users:

• The storage is already stored when the error happens. UserStoragesController::create()
  saves the configuration first and calls updateStorageStatus() afterwards, and the
  crash happens in that status check. The user gets a 500 and no visible storage, then
  finds the storage after reloading the page.
• FTP::getConnection(), MountConfig::getBackendStatus() and
  StoragesController::updateStorageStatus() all catch \Exception. A TypeError is an
  \Error, so it passes through them and surfaces as a hard 500 instead of a
  "storage not available" status.

SFTP had exactly the same problem and it was fixed in #58350
(reported in #58324, #58293, #58507 and #58833). FTP.php never received the equivalent
guard. FTP and SFTP are the only backends that read ['port'].

Steps to reproduce

1. As an administrator, enable Allow users to mount external storage.
2. As a user, open Personal settings → External storage.
3. Add a storage with backend FTP and an authentication mechanism whose credentials
   are available (for example global credentials).
4. Fill in Host, leave Port empty and save.
5. The request fails with a 500, and the log contains the TypeError shown above.
6. Reload the page: the storage is there, because it was saved before the crash.

The same steps with SFTP work, thanks to the guard from #58350.

Fix

Fall back to the default port unless the configured value is numeric, mirroring the SFTP
guard:

$parsedPort = $parameters['port'] ?? null;
$this->port = is_numeric($parsedPort) ? (int)$parsedPort : 21;

21 stays the default, so nothing changes for existing configurations. Casting without
the check would not work, because (int)"" is 0 rather than 21.

Tests

apps/files_external/tests/FtpConstructorTest.php covers the constructor for a missing,
empty, null, non-numeric, numeric-string and integer port. The FTP connection is only
opened lazily, so no FTP server is needed. The test is placed in tests/ rather than
tests/Storage/ because tests/phpunit-autotest-external.xml excludes the latter
directory, and a test there would not run in CI.

I verified the whole files_external suite as well as the Storage/FtpTest.php backend
tests against a real FTP server, and confirmed the new test fails without this change.

Side note

The catch (\Exception $e) blocks mentioned above could be \Throwable, so that this
class of error degrades to a storage status instead of a 500. I left that out to keep
this change minimal, and I am happy to open a separate pull request for it.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Documentation (manuals or wiki) has been updated or is not required

[bahman026]

/backport to stable34

[CarlSchwan]

Suggested change

	/**
	* The FTP connection is established lazily, so the constructor can be covered
	* without a reachable FTP server. The backend tests in Storage/FtpTest.php do
	* need one and are run separately.
	*/

[CarlSchwan]

FtpTest would be more appropriate as class name