never set OperationRepo.enqueue's flush to true

OneSignal.login() was setting OperationRepo.enqueue to true, while this
means the OneSignal backend is updated up to 5 seconds faster it means
a possible increase in load, as not having a delay means we may not
have batched as many network requests.

There is a high chance we will re-introduce the flush via a new public
commit() method, so it wasn't remove in this commit. But before doing
so we need budget rules so it can't be abused.

One oddly I notice here is the login had a flush, but the logout did
not. This seems like a bug, but either way we don't want to flush
anywhere now.

Author: jkasten2

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/core/internal/operations/impl/OperationRepo.kt

@@ -110,6 +110,7 @@ internal class OperationRepo(
         return waiter.waitForWake()
     }
 
+    // WARNING: Never set to true, until budget rules are added, even for internal use!
     private fun internalEnqueue(
         queueItem: OperationQueueItem,
         flush: Boolean,

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/internal/OneSignalImp.kt

@@ -380,7 +380,6 @@ internal class OneSignalImp : IOneSignal, IServiceProvider {
                         externalId,
                         if (currentIdentityExternalId == null) currentIdentityOneSignalId else null,
                     ),
-                    true,
                 )
 
             if (!result) {
@@ -395,7 +394,6 @@ internal class OneSignalImp : IOneSignal, IServiceProvider {
                         configModel!!.appId,
                         identityModelStore!!.model.onesignalId,
                     ),
-                    true,
                 )
             }
         }

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/migrations/RecoverFromDroppedLoginBug.kt

@@ -79,7 +79,6 @@ class RecoverFromDroppedLoginBug(
                 _identityModelStore.model.externalId,
                 null,
             ),
-            true,
         )
     }
 }