Electron 8 & fix App Store submission

[cwillisf]

I wasn't sure who would be best to review this. Please feel free to reassign if you don't have time!

Resolves

Resolves #118
Resolves #119

Proposed Changes

This PR represents a few different changes which ideally would be separated, but because test builds were made with these commits I'm presenting them here as-is.

The most important changes are:

• Add hardenedRuntime: false to the mas section of electron-builder.yaml to resolve Crashing / no main window for Mac App Store reviewers #118
• Add masDev settings to electron-builder.yaml to resolve mas-dev build won't run due to invalid code signature #119
  • Note that building the mas-dev target requires a "Mac Developer" provisioning profile to be placed in the scratch-desktop directory and named macDeveloperThisDevice.provisionprofile. I chose that file name in the hope that it would be somewhat self-documenting.
  • Supporting change: add *.provisionprofile to .gitignore

Other changes include:

• Upgrade dependencies, including an update to Electron 8.2.5
  • This required a few minor code changes
• Add com.apple.security.cs.allow-dyld-environment-variables and com.apple.security.device.microphone to the entitlements for both mac and mas builds.
  • It's unclear to me if these are necessary, but Electron documentation recommends allow-dyld-environment-variables and Apple documentation seems to suggest that com.apple.security.device.microphone should be present if com.apple.security.device.audio-input is in use.
• Use minilog instead of console.log for logging
• Remove uglifyjs to fix a security complaint from npm audit
• A few quality-of-life improvements to the build scripts

Reason for Changes

Fixing the mas-dev build allowed me to test locally. Primarily this was about adding the masDev section in electron-builder.yaml, but I also needed to build app-builder-bin locally with this as-yet-unreleased change: develar/app-builder#34. These two changes fixed #119, allowing me to reproduce the issue that the Mac App Store reviewers have been reporting.

Fixing #118 boiled down to just setting hardenedRuntime: false for the mas build, which is sort of embarrassing given how long it has taken to figure out the problem. In essence, it turns out that electron-builder (or one of its dependencies) doesn't work correctly if hardenedRuntime is enabled and the app's entitlements list includes com.apple.security.app-sandbox. The sandbox entitlement is required for Catalina compatibility, so the solution for now (and maybe forever) is to disable the hardened runtime for Mac App Store builds. See electron/electron#22656 for further discussion on this.

Test Coverage

There are effectively three things to test:

1. Non-store build (mac target): this can be tested with npm start or, for a more strict test, npm run dist.
2. Store build (mas target): we can't really test this locally. We can build it with npm run dist to create the build but only Apple can run it.
3. Store-like development build (mas-dev target): adjust scripts/electron-builder-wrapper.js to build mas-dev instead of mas and run npm run dist, then run the application created in dist/mas-dev.

The build process for each of these requires various digital certificates and provisioning profiles, so practically speaking they can only really be done by a member of the Scratch Team.

I have done all three of these things locally and they all work for me. If you'd like to try this out yourself (and you're a Scratch Team member) I'd be happy to help.

Everyone else: hopefully this PR will help us get the Mac App Store version up to date soon!

[kchadha]

Why not just always return a promise?

[cwillisf]

We talked about this separately but just to record it here: functionally this is fine because it's called with await, which hides the difference between returning a promise and returning a raw Boolean. To avoid possible future problems I will make a followup change where this function always returns a promise, especially since there's basically no down-side to doing so in this context. (This isn't performance-critical, no synchronous work is happening around this call, etc.)

[kchadha]

LGTM other than the question about the function that returns both a promise and a boolean. Seems like that could cause bugs later.

Regardless, I don't think that question has to block this PR