fix: don't silently drop data on short reads in concurrent WriteTo

[ChrisJr404]

Fixes #658.

The concurrent File.WriteTo path (what io.Copy uses) dispatches reads at offsets spaced chunkSize apart and advances the offset unconditionally. Since a server is free to return a short read, and does whenever the client max packet size is larger than the server's, every chunk kept only its first short read and the rest of that chunk was skipped. The copy came back truncated with a nil error, so it was silent corruption rather than an error.

The sequential paths already handle this by looping in readChunkAt. This does the same thing in the worker: when the pre-dispatched read comes back short, fill the rest of the chunk before handing it on, so the pre-computed offsets stay aligned. A genuine EOF ends the fill and is carried through as the chunk's error. The full-read path (server returns the whole chunk) is unchanged.

Added a regression test that opens a file through an in-memory server with a smaller max packet size than the client. It fails on master (WriteTo returns ~1/4 of the file) and passes with this change. go test, go test -race and go vet are green on the package.

[puellanivis]

The problem is this is that we’ve already dispatched reads to later offsets, catch up reads like this result in non-sequential access, which has been a result of various bugs here and there.

Namely, some ssh implementation automatically delete a file once the whole file has been read the first time, this backfilling catch up would break under this situation.

Also, backing up and backfilling can cause significant performance degradation as servers are tuned for sequential read access, not really for random access.