Allow QUIT during an active transfer to defer until transfer completes

[talmakion]

I'm not sure if this is the ideal way to fix this issue, if it introduces other issues, or if the current behaviour is preferred by the developers.

The problem I am having is with blackbox firmware (Cisco IOS and other network vendors) pushing config to an FTP and expecting command pipelining to delay a QUIT until data transfers complete. They are simple clients that just blast commands and wait for sockets to close. Looking at RFC959, this is probably expected behaviour - it's not precisely stated. With current pure-ftpd, this results in aborting mid-transfer and truncated uploads.

My assumption on the RFC appears to be matched by a few other FTP daemons I checked (vsftpd, proftpd and pyftpdlib), only pure-ftpd treated a QUIT like an immediate ABOR.

This fix delays the reaction to a QUIT until all data transfers complete (an ABOR will still kill a transfer as expected), plus it will actually react like a QUIT and cleanup immediately on return to the parser loop, rather than waiting for the client to disconnect.

I've done some one-shot testing of this workaround patch against netkit ftp, ncftp, python 3.10 ftplib, winscp and the problem devices without issue.

[jedisct1]

Looks good!

Thank you for that PR!