bug#34090: URLs / ftp servers the ftp client can't handle well

bug#34090: URLs / ftp servers the ftp client can't handle well

[Caleb Ristvedt]

"guix download ftp://tug.org/historic/systems/texlive/2018/texlive-20180414-texmf.tar.xz"

gets stuck when the progress reporter reports 100%. Strace reveals it's
stuck reading from a socket. Some manual print-statement debugging
confirmed that it's trying to read from the FTP RETR port created by
FTP-RETR in (guix ftp-client), which in turn is trying to read from the
ftp data transfer socket. Initially I thought it was somehow failing to
detect EOF (guile bug or something) because wget managed to download it
just fine, but it actually turns out the EOF isn't being sent at all,
even though the standard pretty clearly states it must be.

Thankfully wget has a --debug flag, so I used that and got this output:
https://paste.debian.net/1060773/

It turns out wget actually gives up on downloading it once, but then
re-opens both control and data connections and resumes where it left off
using the REST ftp command, and that somehow works (it finishes
downloading another 204 bytes and does get EOF).

It seems that our options are either to not try getting stuff from weird
servers like that, or to make our ftp client more robust. For what it's
worth, I remember getting this problem on a smaller download as well
(tens of MB), but don't remember what it was. Anyone have any other URLs
to try from this server?

- reepca