[Core] Make storage class conform to Sendable and subsequent changes

[ncooke3]

Addresses two more Swift 6 errors (with more changes to address the errors from that resulted from the initial changes):

• 💥 Capture of 'self' with non-sendable type 'HeartbeatStorage' in a @Sendable closure
  let oldHeartbeatsBundle = try? load(from: storage)

Needed to conform HeartbeatStorage class to Sendable (requirements).

The problem was the second requirement: Contain only stored properties that are immutable and sendable

private let storage: any Storage // Also needed to be made Sendable

Jumping into the Storage.swift file, the two conforming classes, FileStorage and UserDefaultsStorage, wrapped Foundation APIs FileManager and UserDefaults, respectively. Both Foundation APIs are not Sendable and it would be risky for us to add such conformance. So, I followed the approach discussed in https://forums.developer.apple.com/forums/thread/757527 to remove them as stored properties and instead initialize them in each context they are needed. It's not great, but avoids having to use unchecked Sendable.

• 💥 Capture of 'transform' with non-sendable type '(HeartbeatsBundle?) -> HeartbeatsBundle?' in a @Sendable closure

This is straightforward– DispatchQueue.async takes an Sendable closure so we need to pass it one. This bubbled upwards to the _Objc_HeartbeatController level (this is the public API level used by FirebaseCore module). I re-generated the FirebaseCoreInternal-Swift.h and did not see any difference to the asyncFlush API's signature when adding the @Sendable attribute.

FirebaseCoreInternal and its test suite builds with language mode set to Swift 6. 🎉

#no-changelog

[paulb777]

Is there a way to add Swift 6 compliance testing in CI?

[andrewheard]

Thanks, Nick!

Jumping into the Storage.swift file, the two conforming classes, FileStorage and UserDefaultsStorage, wrapped Foundation APIs FileManager and UserDefaults, respectively. Both Foundation APIs are not Sendable and it would be risky for us to add such conformance. So, I followed the approach discussed in forums.developer.apple.com/forums/thread/757527 to remove them as stored properties and instead initialize them in each context they are needed. It's not great, but avoids having to use unchecked Sendable.

This looks very reasonable to me. I don't think calling, e.g., FileManager.default should be expensive at all. It makes testing slightly more difficult since we can't inject a fake but we weren't doing it for FileManager anyway and you worked around it for UserDefaults. LGTM.