iOS: Add dSYM binaries to without_entitlements.txt

[cbracken]

In #54414, we added dSYM files for physical and simulator binaries in both regular and extension-safe framework builds, but did not add the dSYMs to the without_entitlements.txt list.

This passed all engine pre/post-submit tests, as well as framework tests, but failed during release code signing in Cocoon in a test here:
https://github.com/flutter/cocoon/blob/d849b14bab90e0f90e2f7667e37c9f9a5696b918/cipd_packages/codesign/lib/src/file_codesign_visitor.dart#L305-L313

This adds the missing files to without_entitlements.txt, which fixes a code-signing error as seen in this build log:
https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20Production%20Engine%20Drone/13590/overview

A corresponding change was landed on the flutter-3.24-candidate.1 branch:
#54573

The build associated with that patch correctly completed code signing in this build:
https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20engine_release_builder/688/overview

And more specifically, this sub-build:
https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20Production%20Engine%20Drone/13650/overview

And even more specifically, this build step:
https://logs.chromium.org/logs/dart-internal/buildbucket/cr-buildbucket/8739493904842446705/+/u/Global_generators/Codesign__Volumes_Work_s_w_ir_cache_builder_src_out_release_unsigned_artifacts.zip/codesign_Apple_engine_binaries/stdout

Additionally, this patch adds sky_utils.assert_valid_codesign_config() which fails the script (and thus the build) with an error message if any file in scope for code signing (i.e. Mach-O binaries) is not listed in the code-signing config (entitlements.txt, without_entitlements.txt), or any listed file is not found on disk.

Issue: flutter/flutter#116493
Issue: flutter/flutter#153532

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[jmagman]

Binaries found in files to be zipped:
    Flutter.xcframework/ios-arm64/Flutter.framework/Flutter
    Flutter.xcframework/ios-arm64_x86_64-simulator/Flutter.framework/Flutter
    extension_safe/Flutter.xcframework/ios-arm64/Flutter.framework/Flutter
    extension_safe/Flutter.xcframework/ios-arm64_x86_64-simulator/Flutter.framework/Flutter
    gen_snapshot_arm64
Binaries listed in entitlements.txt/without_entitlements.txt but NOT FOUND:
    Flutter.xcframework/ios-arm64/dSYMs/Flutter.framework.dSYM/Contents/Resources/DWARF/Flutter
    Flutter.xcframework/ios-arm64_x86_64-simulator/dSYMs/Flutter.framework.dSYM/Contents/Resources/DWARF/Flutter
    extension_safe/Flutter.xcframework/ios-arm64/dSYMs/Flutter.framework.dSYM/Contents/Resources/DWARF/Flutter
    extension_safe/Flutter.xcframework/ios-arm64_x86_64-simulator/dSYMs/Flutter.framework.dSYM/Contents/Resources/DWARF/Flutter

[cbracken]

Binaries listed in entitlements.txt/without_entitlements.txt but NOT FOUND:

Ha look at that, checks already catching issues! We only produce dSYMs in release builds, in others the dSYM flag isn't passed. This is actually harmless since the only builds we sign are ones with dSYMs, but we should still generate these correctly.

It's painful enough just testing the seven builds required to do release build testing locally, so hadn't been testing debug/profile cases locally on top of it. One more conditional and we should be good.

[cbracken]

Alrighty, here we go again.

[jmagman]

I may be misremembering but aren't dSYM usually only generated for release mode? I don't think it bakes the symbols into the debug binary (for linker speed) but there's some other mechanism for how it works? I don't exactly recall though.
I would think if debug crashes aren't currently symbolicated we would need the dSYMs.

[cbracken]

I may be misremembering but aren't dSYM usually only generated for release mode?

Yep that's exactly what I was saying here, though perhaps badly. We now (as of this commit) only add them if the --dsym flag is passed. And that flag is only passed in release mode.

engine/ci/builders/mac_ios_engine.json

Line 511 in 97e990c

"--dsym",

I would think if debug crashes aren't currently symbolicated we would need the dSYMs.

Debug/Profile builds aren't stripped, so they're properly symbolicated as-is. The release builds are the only ones we strip (here):

engine/ci/builders/mac_ios_engine.json

Line 512 in 97e990c

"--strip"

[jmagman]

Tests! Tests! Tests! Tests! Tests! Tests!