Fix issue with migration from v4 to v5 when obfuscation is used by the app

[brismithers]

Description

One Line Summary

Fix issue with migration from v4 to v5 when obfuscation is used by the app

Details

The v5 SDK will read/write to a preference store called "OneSignal", it is defined as a string so it is always expected a file at /data/data/<app_id>/shared_prefs/OneSignal.xml . The v4 SDK however will read/write to a preference store defined as OneSignal.class.getSimpleName(); (see here).

When an app is using ProGuard (or similar) the OneSignal class name can be renamed, as a result the underlying preference store for v4 can be named anything. So when going from v4 -> v5 (or even different builds of v4 to v4), on startup the SDK does not find the preference store and believes it is starting "fresh", resulting in a new subscription for the device.

Since we don't know what name was used, the underlying fix is to scan the existing preference stores to find the correct one and rename it to "OneSignal.xml", which is the static name as of v5.

Motivation

Desire to only have 1 subscription per device across app builds.

Scope

This fix is a startup/initialization fix targeting devices that have a new app install migrating from SDK v4 to SDK v5.

Testing

Manual testing

1. On an emulator, run as a fresh install the OneSignal Example app on v4, but modifying the PREFS_ONESIGNAL value to a static string like "g3" (pick any string). A new subscriber should be created when started.
2. On the same emulator and without uninstalling the v4 version, run the OneSignal example app on this version of the SDK.
3. When OneSignal.initWithContext is called the preference file should be appropriately renamed, and the subscriber created from the v4 SDK version is used by the v5 SDK.

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 

[shepherd-l]

I noticed that the linting check fails. The linting fix has been merged and it should be working as intended now

Could you fix the linting errors? I could also do it as well

[brismithers]

Done