This PR adds support for sending NOOP commands every 15 seconds (or whatever value you've set NoopInterval) in order to keep the control socket alive during long file transfers.

It fixes the long standing issue: Timed out trying to read data from the socket stream!

Related PR: #507

Fixes issues: #122, #387, #453, #297, #293, #256, #253, #245, #244, #156, #55

It seems that the AzureVM router or firewall does not respect TCP Keep-Alive on the control socket (port 21). When large file transfers runs on data socket (20 or passive) there is no traffic on the control socket and it breaks for us after ~280s (perhaps 240s). Before mentioned workaround setting EnableThreadSafeDataConnections = true simply caused the exception from the broken connection to be discarded, pretending all was fine and opening a new control socket.

The NOOP command responds something like '200 NOOP command successful.' and is typically used by a FTP UI client to keep the control socket alive in-between commands, so it is a good candidate for using also during long-running command executios (i.e. RETR/STOR). However the https://tools.ietf.org/html/rfc959 neither suggests that nor against it.

Indeed, googling shows that it has been proven in battle, with some odd complaints (see link to smartftp.com some comments back) that it could potentially cause file transfers to abort (remains to be proven) or make FTP servers behave strangely like not responding 200 (that is what I can see from IIS) or respond at the end of the file transfer (have no such evidence, but pull request attempted to cope with that in a rudimentary manner).

Suggested usage for NoopInterval (in milliseconds) from our experience;

• 0 (default) if you can get away with it do not fiddle with it, keeping in mind that sending commands during command execution might not be by the book for all FTP server implementations out there
• firewall timeout divided by 2, if you can determine the timeout by transferring files 10MB, 50MB, 100MB, 500MB, 1GB, 5GB
• 30000 or 45000 or 90000 (corresponding to 30s, 45s or 90s) would make sense
• not something like 1000 or 5000, that would be nonsensical because any socket must survive 5s silence, problem should be sought elsewhere like in the firewall