Resume failed downloads

[HebaruSan]

Motivations

Currently if a mod download fails partway through, the already downloaded bytes are lost and have to be re-downloaded, which wastes time and network capacity.

Mods are initially downloaded to the system temp folder, which the user may not know how to control and which may not be very large, whereas the user would probably choose a high capacity drive for their download cache.

I've been trying to improve our network handling for the next release, see #3624, #3631, #3635, #3645, and #3659. This is the next big piece now that I'm warmed up.

Changes

• Mods are now downloaded to a downloading subfolder of the main cache folder, so they will be included on that same device unless the user does some really crazy mount commands to mess with us
  • A download that fails partway through will leave behind the in progress file in that folder
  • The same {hash}-{description}.zip file name format is used and queried as for the main cache, so we can easily find the matching file
  • A download that starts with an in progress file already available will skip the bytes already on disk and resume the download where the previous one left off
  • The cache folder size displayed in the settings now includes this extra folder
  • The cache limit setting now includes partial downloads in its enforcement
  • We no longer check the temp folder's free space (see Check free space before downloading #3631)
• We had two WebClient derived classes in Net.cs, which are now moved to their own files under Core/Net
• A third WebClient derived class, ResumingWebClient, is created in its own file and:
  • Opens its output file for appending rather than truncating it
  • Calls HttpWebRequest.AddRange to tell the server to skip bytes we already have
  • Handles HTTP code 416 by skipping the download, since this is thrown if we have the complete file already in the in progress folder (special corner case)
  • Uses a special CopyTo variant with progress reporting, because contrary to the documentation, DownloadProgressChanged is not fired after using OpenReadAsync
    • And we use our own event because we aren't allowed to create the parameter objects of DownloadProgressChanged
• NetAsyncDownloader uses ResumingWebClient to support resuming interrupted downloads
• If a mod is not cached but has a partial download on disk, the changelog, recommendations, and dependency-choosing screens show the size remaining instead of the total:
  
  • The code for this is now centralized in NetModuleCache.DescribeAvailability, and the corresponding i18n strings are migrated from GUI to Core

After these changes, if a download fails partway through and you try it again, it resumes where it left off. Completed downloads must still pass the gauntlet of NetModuleCache.Store, which checks file sizes, hashes, and ZIP validity, so if the network corrupts a download, we will throw errors rather than trying to use it.

[techman83]

Ok, that's super neat!