🎯 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.