Fix random Hash Mismatch errors

[sarpt]

After delivery of #251 I've noticed that when downloading a lot of small packages at once there is quite a high chance of getting a "Hash mismatch" error even though clicking "Download" again and hashing the file second time results in a successful hash calculation suggesting a false negative.
I've noticed that after all write_all calls there doesn't seem to be a flush which awaits until all chunks are actually on disk. Adding this flush seems to have fixed the issue and hashing no longer has a random chance to start and read file size from metadata before everything's on disk.

[RainbowCookie32]

Looking at tokio's docs, apparently the right method in this situation would be sync_all. According to the docs, flush just ensures that the file is closed as soon as the handle is dropped.
Confusingly enough, the flush method on std seems to actually flush pending buffers, but it's a no-op on Windows and Unix.

[sarpt]

Looking at tokio's docs, apparently the right method in this situation would be sync_all. According to the docs, flush just ensures that the file is closed as soon as the handle is dropped. Confusingly enough, the flush method on std seems to actually flush pending buffers, but it's a no-op on Windows and Unix.

I changed to sync_all. Seems I mistook std's with Tokio's behavior. Whatever flush did seems it only lessened the probability of the issue instead of fixing it completely then.