Improve verification and recovery for corrupted downloads

[freakboy3742]

It is possible for support packages and tool downloads to be corrupted during download; this can lead to a confusing situation where a user has a corrupted support file (or other resource), but the file exists, so Briefcase doesn't try to re-download the file. (e.g., beeware/beeware#157)

Describe the solution you'd like

Briefcase should have a more robust recovery mechanism for dealing with corrupted downloads. This could include:

• Verifiying checksums at time of download. This may not be easy to implement, as there's no consistent standard for how to publish the checksum of a file for automated verification.
• When an attempt to unpack an archive fails due to an apparent corrupted file, the original file is automatically deleted (or moved aside) so that a retry of the same command will cause a re-download.
• A user-accessible mechanism to manually flush the download cache (e.g., an option on briefcase upgrade to clear the support file cache). This could be combined with a "purge old support packages" command (e.g., no need to keep b1, b2 and b3 if b4 is available).
• A flag on commands that forces files to be re-downloaded (e.g., briefcase create --always-download will always re-download the support file, even if it already exists. I'm not in love with --always-download as a name; other suggestions welcome)

Describe alternatives you've considered

Status quo is to manually delete the problem files from ~/.briefcase/support, but that folder isn't obvious to the end user.

[mhsmith]

I think by far the most likely cause of this problem is the download being interrupted before it finished. That could be fixed by downloading to a temporary filename and then renaming if it completed without error.

[freakboy3742]

Yes - using a temp name wouldn't be bulletproof, but it should definitely resolve a lot of problems.

The only thing to be wary of is the location of the temp file - if we just append ".tmp" to the filename in the final location, we could end up with stray partial download files that are difficult for users to find and are never cleaned up - or, even worse, we could end up with collisions on the temp file name. We either need to be very careful about doing pre/post download cleanup, or make use of temporary directories to ensure that there won't be collisions.

[mhsmith]

A common way of dealing with this is to include the process ID in the filename. That way, it's guaranteed to be unique at any point in time, so in the unlikely event that there's an existing file with the same ID, it can safely be overwritten.

It also accommodates two Briefcase processes downloading the same file at the same time. But the second process to finish downloading must be able to deal with the target filename already existing, which would cause the rename to fail on Windows if the first process currently had the file open.

[rmartin16]

Downloading to a temporary file and only renaming it to the permanent file if the download completely successfully was implemented in #956.