Use 1xx as expected response when requesting a data connection

[suddjian]

I have an issue where when I call StoreFile, the server responds with 125 Data connection already open; Transfer starting., which this library treats as an unexpected code and incorrectly aborts the transfer.

I don't have control over this server, and I'm not sure why it is responding this way (I am only opening one connection in a simple script to store one file, and I always close the connection afterwards). But regardless, 125 is not actually an error code, and if we treat it as a success code the file still gets uploaded just fine.

So this commit changes the expected response to 1xx, which should match any positive response, as described here.

[marcobeierer]

Hi @ChemicalRocketeer

Thank you for your pull requests. I had a look at the issue and you are absolutely right, we shouldn't abort on status code 125.

Unfortunately I think your fix introduces new issues. When I understand it correctly, we cannot process normally when we receive status code 110 or 120. 120 for example means Service ready in nnn minutes. and it is necessary to handle this situation if we accept all 1xx status codes... Also 110 seems to need special handling.

If I look at the code it seems that accepting just the status codes 125 and 150 isn't a quick fix as it needs some refactoring...