[Fix] RecoverFromDroppedLoginBug not running in very rare cases

[jkasten2]

Description

One Line Summary

Fix a very rare case where RecoverFromDroppedLoginBug may not run.

Details

Motivation

We want to ensure RecoverFromDroppedLoginBug always runs, otherwise we can't recover some end-users who would be stuck in a bad state, where the OperationRepo queue stalls. While the case where this would happen would be extremely rare, the orignal code had a landmine, where if initialization code was refactored the rare case could be become much more common. The existing Unit Test did not cover out of order initialization either.

Scope

Only affects RecoverFromDroppedLoginBug.kt

Testing

Unit testing

• New failing test to prove issue
• Test is passing and was also refactored in the same commit as the interface changed.

Manual testing

On a Android 6 emulator ensured RecoverFromDroppedLoginBug.isInBadState() runs.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jkasten2]

Flaky unrelated test: Fixed this in PR #2083

com.onesignal.core.internal.http.HttpClientTests > ensure next request is delayed by the Retry-After value FAILED
    java.lang.AssertionError: Expected null but actual was com.onesignal.core.internal.http.HttpResponse@6e229864
        at com.onesignal.core.internal.http.HttpClientTests$1$11.invokeSuspend(HttpClientTests.kt:252)
        Caused by:
        java.lang.AssertionError: Expected null but actual was com.onesignal.core.internal.http.HttpResponse@6e229864
            at com.onesignal.core.internal.http.HttpClientTests$1$11.invokeSuspend(HttpClientTests.kt:252)

[jinliu9508]

LGTM!

While we have discussed moving the initialization process to the constructor as a potential solution for now, this approach is more precise and can prevent potential breakdowns resulting from future refactors.