Avoid duplicate MuxUpload initialization in UploadManager

[andrewjl-mux]

This PR contains a fix for MuxUpload progress reporting callbacks going silent mid-upload. The actual upload completes and is successfully delivered so the issue is limited to callbacks. To make this fix work UploadManager will store MuxUpload and not ChunkedFileUploader.

UploadManager external-facing API is unchanged.

Root cause analysis

UploadManager exposes a means of subscribing to notifications when a managed MuxUpload starts and finishes network transport.

UploadManager stores ChunkedFileUploader instances by key in a dictionary (hash map). When the dictionary content changes, UploadManager emits a delegate callback and provides its delegates with an updated list of entities corresponding to each ChunkedFileUploader.

Since ChunkedFileUploader is an internal class and the delegates of the UploadManager may be internal or external to the package, the delegate callback converts the list of ChunkedFileUploader to a list of MuxUpload by initializing a new MuxUpload for each key-value pair. A new MuxUpload gets initialized per delegate method call. Every MuxUpload emitted this way is different, when it comes to pointer identity, from the original MuxUpload initialized by the SDK client.

No MuxUpload coming from UploadManager will have its handler properties set with the SDK clients original closures. This triggers the bug.

If the SDK client does not retain the MuxUpload it originally created (and the example code in our case does not retain the original MuxUpload, it replaces it with whatever it gets from UploadManager) then the original MuxUpload is deallocated because the SDK doesn't retain it either.

This wasn't obvious when first introduced because the example code reset the callback handlers during each SwiftUI update cycle, the callbacks usually propagate an update unless a race condition is triggered: where a callback runs before a new handler is set but after the previous MuxUpload is deallocated.

[cjpillsbury]

question(non-blocking): Were these changes to the DEVELOPMENT_TEAM intentional? If no, revert?

[andrewjl-mux]

Good catch, this shouldn't be here, I'll revert

[andrewjl-mux]

Removed

[cjpillsbury]

The high level description of the PR makes sense to me (🙏 for the great overview). Code also looks reasonable (to the best of my ability, obv). Had a couple of nb callouts but otherwise 😎 good find/fix.