Fix possible deadlock in CurrentChatUser functions

[b-onc]

🔗 Issue Links

https://getstream.slack.com/archives/CRB9P6L03/p1654667559058219

🎯 Goal

A customer has reported that calling addDevice causes a deadlock

📝 Summary

Calling addDevice twice, once from background queue and once from main queue causes deadlock:
background queue -> acquires the lock (semaphore), waits on main queue because of performAndWait
main queue -> waits on the lock, cannot perform any work

🛠 Implementation

EntityDatabaseObserver uses viewContext for its DB operations, both in tests and production code. This is because it needs to be performant.

When you try to access EntityDatabaseObserver.item from background queue, since it's an Atomic, it acquires the lock & calls viewContext.performAndWait (to convert DTO to Model) which waits for main queue to complete some work

If you try to access EntityDatabaseObserver.item from main queue, it'll wait on the lock... which is held by background queue, which is waiting on main queue (because of performAndWait), which is waiting on background queue to release the lock, which is waiting on main queue to complete the work, which is waiting on background queue to release the lock......

We cannot "fix" the bug in EntityDatabaseObserver right away, it's complicated. But the bug happens because we access currentUser, which is currentUserObserver.item in the CurrentUserController. This causes DB operations, which is not required, we already have O(1) access to currentUserId, which is all we need.

The patch in this PR will mitigate this issue for now.

🧪 Manual Testing Notes

Paste this in EntityDatabaseObserver_Tests

func test_deadlock() throws {
        let testId: String = .unique
        fetchRequest.predicate = NSPredicate(format: "testId == %@", testId)
        
        // Insert the item matching the predicate
        try database.writeSynchronously {
            let context = $0 as! NSManagedObjectContext
            let new = NSEntityDescription.insertNewObject(forEntityName: "TestManagedObject", into: context) as! TestManagedObject
            new.testId = testId
            new.testValue = .unique
        }
        
        try observer.startObserving()
        
        // Read item.value from background queue
        DispatchQueue.global().async {
            XCTAssertEqual(self.observer.item?.id, testId)
        }
        
        // Sleep main thread for a little time
        // to make sure background thread acquires lock
        // if we don't sleep, main thread acquires lock first & no deadlock occurs
        sleep(1)
        
        // Read item.value from main queue
        XCTAssertEqual(self.observer.item?.id, testId)
    }

☑️ Contributor Checklist

• I have signed the Stream CLA (required)
• Changelog is updated with client-facing changes
• New code is covered by unit tests
• This change follows zero ⚠️ policy (required)
• Comparison screenshots added for visual changes
• Affected documentation updated (docusaurus, tutorial, CMS)

[evsaev]

Can we have a unit test for at least one method?

[b-onc]

@evsaev Done! they were failing anyway....

[evsaev]

LGTM!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication