Manage stub binaries as external resources

[freakboy3742]

The macOS and Windows app templates include a stub binary; however these binaries are currently managed as artefacts in the macOS/Windows app template. As the template is git repository, it contains the full history of all changes to the template; as a result, on first use, the user must download all historical stub binaries as part of the template.

This change modifies the handling of stub binaries so that they are external artefacts, analogous to the support package. They will be stored on S3, same as the support packages, and cached on use; however, as they're managed as external resources, the base template can be made a lot smaller.

This change by itself won't reduce the size of the template checkout, as cookiecutter does a full repo clone. #1855 adds a modification that does a blobless clone, which will reduce the size of the initial repository clone.

This change requires a template update to take full effect; but, conveniently, CI will pass without any changes, because the stub binary that is unpacked from a downloaded archive has the same name as the stub binary that is generated by the current app template, and the current app template doesn't have the marker that indicates a stub needs to be downloaded.

Refs beeware/briefcase-macOS-app-template#58
Refs beeware/briefcase-windows-app-template#51

Fixes #933.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

As we discussed yesterday, the way this will work is:

• Update the VisualStudio or Xcode repository.
• Apply a tag in the app repository.
• This triggers a GitHub Action which builds an app from the VisualStudio or Xcode repository, and uploads the stub executables to S3 with a build number from the tag.
• Test the executables manually using the stub_binary setting.
• Update briefcase.toml in the app repository with the build number from the tag.

This means that in the app repository, the tag for each build will always be on the commit before that build was adopted, e.g. the tag for build 6 will always be on a commit that says stub_binary_revision = 5.

Also, there's no direct link between the stubs and the source code they were built from. You'd have to work it out by comparing the timestamps of the two repositories.

These could both be fixed if the tags and the actions were moved to the VisualStudio or Xcode repository instead.

[freakboy3742]

These could both be fixed if the tags and the actions were moved to the VisualStudio or Xcode repository instead.

I thought about that; I wasn't sure if it was odd to have something that only the app template uses being controlled by a different repo. However, your point about having a tag on the exact code being used is a good one that I hadn't considered. I'll put up PRs to migrate the binary tagging over to the Xcode/VS template repo.