[Feature Request] Expose libssh timeouts and add safe transfer cancellation

[MansiVisuals]

Hi, thank you for maintaining MFT.

Would it be possible to add connection/transfer timeout support and safe cancellation for stalled uploads or downloads?

I’m using MFT in an iOS File Provider extension, where transfers can run on unreliable mobile networks. MFT’s progress callback works well while bytes are moving, but if a connection stalls completely and no callback arrives, there is no supported way to stop the active transfer.

Calling [disconnect] from another queue is risky because MFTSftpConnection is not thread-safe.
A timeout or cancellation mechanism managed inside MFT would let apps fail the transfer cleanly and retry using a fresh connection.

Since MFT already uses libssh, perhaps its timeout options could be exposed through MFT. This would be very helpful for mobile and background synchronization use cases.

[MansiVisuals]

I opened #7 with part of this: a connectionTimeout property that sets SSH_OPTIONS_TIMEOUT and SSH_OPTIONS_TIMEOUT_USEC before connecting, defaulting to 0 so current behaviour is unchanged. It comes with a test that accepts a connection and then stays silent, so it covers an unresponsive server rather than a refused one.

I did not manage the other two parts. An idle timeout for a stalled transfer, implemented by polling the AIO calls, does not fire: sftp_aio_wait_read only returns SSH_AGAIN when the file handle is nonblocking, and the packet read underneath still blocks while the session is blocking, so the polling thread never gets control back. Making the session nonblocking too broke transfers outright. Cancellation of an in-flight transfer runs into the same thing, since it would be noticed between the same polls.

One useful side effect: SSH_OPTIONS_TIMEOUT also bounds reads during a transfer, so a stalled download now fails instead of hanging. Testing on a device, a transfer interrupted mid-stream failed after the configured 20s and recovered on the next attempt. That covers much of what I originally needed here, even though it is a per-read bound rather than a real idle timeout.

[mplpl]

Thanks @MansiVisuals for proposing this feature and committing the code.