fix(db): improve IndexedDB error handling and optimization

[fadi-george]

Description

1 Line Summary

Improves IndexedDB error handling by adding database availability checks during initialization and optimizes database operations by replacing the idb library with a lightweight custom implementation.

See ticket: https://app.asana.com/1/780103692902078/project/1208777190614537/task/1213397971882709?focus=true

Details

IndexedDB is our local storage system for preserving info on subscription, user, and other details. Currently when a user goes to chrome settings to delete data from site:

It will corrupt the IDB so when going back to the tab and refreshing, the developer might see:

New changes will just one check in init and use our Log helper if there's an error.

• Adds early database availability validation in OneSignal initialization to prevent crashes when IndexedDB is unavailable. Replaces the external idb dependency with a custom lightweight IndexedDB wrapper to reduce bundle size and give use more control.
• Moves external id logic (from UserNamespace) to User class since if IDB is not available, then we don't want to use Model info which may rely on IDB.
• Updates IDB/client test to use our simpler IDB promise methods
• Updates init call to check against db promise to see if IDB can loaded otherwise will return early. OneSignal.User.<some-action really on user class being loaded in init but will remain undefined if IDB fails to load. Calls like OneSIgnal.User.PushSubscription.optIn (not reliant on user class) use awaitOneSignalInitAndSupported which will be a floating/unresolvable promise. This means it won't preform any action/updates if IDB fails to load.

Systems Affected

• WebSDK
• Backend
• Dashboard

Validation

Tests

Info

Database client tests updated to work with the new custom IndexedDB implementation while maintaining existing functionality.

Checklist

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

Programming Checklist
Interfaces:

• Don't use default export
• New interfaces are in model files

Functions:

• Don't use default export
• All function signatures have return types
• Helpers should not access any data but rather be given the data to operate on.

Typescript:

• No Typescript warnings
• Avoid silencing null/undefined warnings with the exclamation point

Other:

• Iteration: refrain from using elem of array syntax. Prefer forEach or use map
• Avoid using global OneSignal accessor for context if possible. Instead, we can pass it to function/constructor so that we don't call OneSignal.context

Screenshots

Info

Checklist

• I have included screenshots/recordings of the intended results or explained why they are not needed

---

Related Tickets

---

---

This change is