feat: improve update kits performance

[willpassidomo]

Summary

This greatly improves performance for our updateKits() function, specifically with respect to main thread usage. We found that very large kit configurations result in significant periods of main thread usage. The problem occurs primarily during kit configuration parsing and occurs both when the kits are initially loaded and every time Consent State is update, every time the current MParticleUser changes, and every time Opt in/Opt out status is changed.

When kits are initially loaded, it is unavoidable that we need to parse the kit configuration. To avoid excessive main thread usage, this parsing now takes place on a dedicated background thread.

For the latter situations (Consent State, opt-in, and User change), we should not have to re-parse the kit configuration, since the kit configuration has not changed. To solve this, we will now retain references to the parsed KitConfiguation instances and reuse them.

KitLoadedCallback and KitManager#updateKits() signature change

Since we are now parsing on a background thread, the updateKits() method became asynchronous, so we updated the signature to return a KitLoadedCallback instance. This was required to keep the kitsLoaded status change as well as queuing state changes in KitFrameworkWrapper accurate, otherwise, we would be dequeuing before kits might have been fully loaded

I also chose to move the dequeing update logic to KitFrameworkWrapper. With these changes it is difficult to tell, from KitManagerImpl, whether we are performing a kit reload before a config had been loaded (no cached config) or if we have loaded a bonified kit configuration. Regardless, KitFrameworkWrapper seems like the more appropriate responsible class anyway to handle this since it is essentially the "manager of the KitManager"

Remove ConfigManager#reloadKitConfig()

During testing I discovered that we are "reloading" any cached configuration twice, once when the loadKitFramework() call is made from UploadHandler and once on ConfigManager#delayedStart(). I removed the latter instance since the former will have already taken place by the time it was called

Testing Plan

• {explain how this has been tested, and what additional testing should be done}

Master Issue

• Closes https://go.mparticle.com/work/SQDSDKS-2992

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[mparticle-automation]

🎉 This PR is included in version 5.37.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀