Fix Storage Emulator crash on iOS auth error for resumable uploads

[tohhsinpei]

Description

Issue(s)

Follow up to #4184. This PR fixes #3550, #3584, #3765, and #3890.

Previously, we fixed the issue where the iOS client receives a permissions error despite being authenticated to make a write. However, we still need to address the issue where the Storage Emulator crashes on any such permissions error.

Cause

When the upload request is finalised, the file is moved. When the iOS client subsequently receives a 403, it cancels the request. During the cancel, the emulator attempts to delete the file at its old temporary location, resulting in the following error:

Error: ENOENT: no such file or directory, unlink '/var/folders/jt/rrd3wxwj09bd2twr6cxdx1z80000gn/T/firebase/storage/blobs/d08a3410-0980-4fbe-b46c-eb4111ad46e9_b_my-new-app.appspot.com_o_aGtgkgT04cudlZXaPFC72R9tZMlv%2FINSPJ6MFM%2FjxRlG6mkqJAesWsyBpYb%2F1625387702%2Fimg%2F16253877290.jpeg'
    at Object.unlinkSync (node:fs:1708:3)
    at Persistence.deleteFile (/usr/local/lib/node_modules/firebase-tools/lib/emulator/storage/files.js:478:18)
    at StorageLayer.cancelUpload (/usr/local/lib/node_modules/firebase-tools/lib/emulator/storage/files.js:152:27)
    at handleUpload (/usr/local/lib/node_modules/firebase-tools/lib/emulator/storage/apis/firebase.js:366:45)
    at /usr/local/lib/node_modules/firebase-tools/lib/emulator/storage/apis/firebase.js:443:24

Scenarios Tested

Tested against example linked in issue and verified that crash does not occur after fix. Also tested with storage rules that always give an auth error, i.e. allow read, write: if false.

[tonyjhuang]

Capturing some of what we synced on offline:

There seems to be a bigger bug in our handling of finalize upload requests. Namely, we call StorageLayer.finalizeUpload before we evaluate rules which marks the upload as successful and triggers any CREATE Cloud Functions. Additionally, using StorageLayer.deleteFile to clean up our persistence layer if auth fails has the unintended side effect of triggering any DELETE Cloud Functions.

My take is that we probably want to refactor the finalize upload handler in firebase.ts to only call StorageLayer.finalizeUpload after rules evaluation. Unfortunately, it seems that we use StorageLayer.getMetadata to pass some metadata to rules and in its current form, it requires the file be persisted to the internal memory store (StorageLayer._files), so some additional refactoring may be required.

[tonyjhuang]

Overall lgtm, just a few small remaining comments

[tonyjhuang]

can you add an assertion in this test case or another that ensures the querying for the upload after a cancel denotes that the upload was cancelled?

go/unified-upload-protocols#ended-uploads

[tohhsinpei]

I'm not sure we're doing this now actually 😅 But I would fix this in another PR.

[tonyjhuang]

Thanks for the fix