Prevent potential duplicate calls to CreateDevice

[VelikovPetar]

🎯 Goal

We still have reports of the CreateDevice endpoint hitting rate limits. In this PR we introduce another level of guarding against duplicate calls, by introducing a local tracking of the device registered in the current session, plus a locking mechanism.

🛠 Implementation details

• Tie the device registration process to the currently logged in user (note: the CreateDevice/DeleteDevice endpoints will fail if called without a connected user) to support the case where different users a switched in the same ChatClient
• Introduce an additional check in the PushTokenUpdateHandler#addDevice: check if the same token was registered previously in the current session (in addition to the check agains user.devices)
• Add a locking mechanism to prevent multiple CreateDevice invocations at the same time
• Additionally do some small clean-up in the DeviceApi and ChatApi by removing unnecessary parameters

🎨 UI Changes

NA

🧪 Testing

Pretty difficult to test in a real-world scenario. One possible scenario to test is to manually delete the firebase token:

FirebaseMessaging.getInstance().deleteToken()

Then put the app in background, and then back to foreground. There should be two attempts to register the new token:

1. via onNewToken
2. when user is reconnected

But only one CreateDevice should be fired.

Another possibility is to simulate repeated calls to FirebaseMessagingDelegate.registerPushDevice - again, only one CreateDevice should be fired.

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-chat-android-client	5.25 MB	5.25 MB	0.00 MB	🟢
stream-chat-android-offline	5.48 MB	5.48 MB	0.00 MB	🟢
stream-chat-android-ui-components	10.59 MB	10.59 MB	0.00 MB	🟢
stream-chat-android-compose	12.81 MB	12.81 MB	0.00 MB	🟢

[andremion]

I can't reproduce the issue even on develop

I deleted the token, then background, then foreground, but found one request POST https://chat.stream-io-api.com/devices

[sonarqubecloud]

Quality Gate failed

Failed conditions
68.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud