There are three categories of binaries produced as part of the framework artifacts:
* Those that use APIs that require entitlements and must be code-signed; e.g. gen_snapshot
* Those that do not use APIs that require entitlements and must be code-signed; e.g. Flutter.framework dylib.
* Those that do not need to be code-signed; e.g. Flutter.dSYM symbols.
We are adding the third category in https://github.com/flutter/engine/pull/54977. The Cocoon code signing aspect of this was handled in https://github.com/flutter/cocoon/pull/3890.
This ensures these files don't get copied into the build output should they appear in the artifact cache.
Issue: https://github.com/flutter/flutter/issues/154571
All of the network requests from google cloud storage include an x-goog-hash header which contains an MD5 checksum. If present, use to validate that the downloaded binary is valid. This will rule out corrupt files as the cause of getting started crashers in the flutter_tool.
#38980
This does not fully resolve the above issue, because while we can check if the checksum matches what was expected from cloud storage, this A) may not necessarily be present and B) may not match up to what should be uploaded as part of the engine build process.
But when life gives you lemons you hash those lemons using an outdated hashing algorithm.
Any File-derived IOSink may throw un-handleable async exceptions into the zone, see dart-lang/sdk#43663 . Instead, just write to a file with an append mode.
Like the ProcessException thrown from zip running on a bad file, the tool should catch the ArchiveException thrown from windows implementation using package:archive.
Exit the tool after a repeated network error to download. previously we were returning null and continuing on, leading to a ProcessException when we unzipped a missing file.
