[Bug] The getter for WorkManager considers the app context

[nan-li]

Description

One Line Summary

Allow custom work manager to be initialized on demand, which resolves Hilt dependency manager conflict.

Details

• With helpful comments from the community and revisiting WorkManager source code.
• We were mimicking the isInitialized() API that checks for a WorkManager instance via WorkManagerImpl.getInstance() and initializing it with a blank Configuration when the getter returned null.
• However, we should use WorkManagerImpl.getInstance(Context) instead as this getter will allow for on-demand initialization with the app's custom WorkManager.
• Because Hilt dependency manager or other app configurations such as using lateinit may not have the WorkManager instance initialized at the time we check.

Motivation

• Fixes [Bug]: Version 4.8.5 breaks Hilt dependency injection of CoroutineWorkers #1748 for user model

Scope

Work Manager initialization.

Testing

Unit testing

• None due to limited ability to reproduce original crashes
• Except to run a bare unit test that experiences the original "not found" crash when given a unit test context.
• Then using the OSWorkManagerHelper's getter instead does not crash and returns a new Work Manager instance.

test("start application service with non-activity shows entry state as closed") {
    // Crashes
    WorkManager.getInstance(ApplicationProvider.getApplicationContext<Context>())

    // Works
    OSWorkManagerHelper.getInstance(ApplicationProvider.getApplicationContext<Context>())
}

Manual testing

Limited ability to test manually due to unable to reproduce original crash

• Tested normal app flow in an emulator
• Receiving notifications in background and swiped away state
• Opening app, etc.
• Receive receipt worker runs and succeeds

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
• 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.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is