build: remove dead symlink from MAS build

[MarshallOfSound]

Fixes #23828

This fixes the stray symbolic link and adds a script to ensure it doesn't happen again

Notes: Fixed mac app store rejection notice for invalid symbolic link in bundle.

[nornagon]

This is a reland of #23831?

[MarshallOfSound]

@nornagon Yes but with a more correct fix for the gn check failures, the MAS build now truly doesn't depend on any parts of the crash component

[release-clerk]

Release Notes Persisted

Fixed mac app store rejection notice for invalid symbolic link in bundle.

[trop]

I was unable to backport this PR to "9-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "10-x-y", please check out #24166

[deepak1556]

Some crash symbols still leak through by

//electron:electron_lib --[private]-->
//electron/chromium_src:chrome --[public]-->
//chrome/common:common --[private]-->
//components/crash/core/app:app

if symbols should be completely removed in MAS build then this path should be addressed.

[nornagon]

I don't think symbols are the issue here, I think it's API calls? So as long as we're not calling things that don't work in MAS, we're OK.

[deepak1556]

I am not sure too, @MarshallOfSound can you please clarify the end goal of conditionally including those deps. If symbols are not an issue, I would like to add //components/crash/core/app back and remove the nogncheck

[MarshallOfSound]

@deepak1556 It's a combination. The original goal was to completely remove the crash component as a dependency to guarantee that MAS build can't call anything in there that straight up won't work. If there's a dependency chain I missed I can follow up to remove that.

The actual problem this PR solves is twofold.

(1) The Helpers folder needs to not exist on MAS builds, this requires changing some GN config
(2) The MAS build needs to not end up binding to, or calling, any crash methods (so this introduces some new noop / stub methods)

I think the dependency chain you posted can be removed by patching out the dependency for mas builds

[deepak1556]

Thanks for the context!

Removing the dependency chain from //chrome is a patch that we have to maintain always. With the electron crash api sources, Helpers framework and crashpad_handler_syms excluded, can we just build the deps unconditionally ?

[MarshallOfSound]

With the electron crash api sources, Helpers framework and crashpad_handler_syms excluded, can we just build the deps unconditionally ?

The Helpers and syms are completely excluded but the electron_api_crash_reporter files and a few others are left in and we rely on MAS_BUILD defined checks to ensure we aren't doing The Wrong Thing in a mas build. It would be way safer to ensure it's impossible link those symbols into the MAS build accidentally. I don't know how big of a patch that would end up looking like though.

[deepak1556]

Hmm, this is a unique case where it is not completely necessary to remove the symbols but at the same time want to ensure headers are behind #if defined. I am fine with ignoring the symbols coming from //chrome, I don't think a patch is worth it.

[davidwinter]

Will this be backported to v9?

[trop]

@MarshallOfSound has manually backported this PR to "9-x-y", please check out #24238