feat: Add configMaxAge to MParticleOptions

[willpassidomo]

(moved from internal repo)

Summary

Add public API for setting a max config staleness parameter. If the config is older than staleness limit, we will delete it instead of loading it from memory while we wait for the new config

Usage

val options = MParticleOptions.builder(context)
   .maxConfigAge(1000 * 60 * 60 * 24 * 7)                   <- set a max age of 1 week
   .build()

note: maxConfigAge value is DAYS SECONDS

API Behavior

• not setting maxConfigAge will default it to null which means it will not take effect and the SDK will behave exactly how it currently does
• setting it to a negative Integer will trigger a warning-level log message then proceed as if it was null (same as above)
• setting it to 0 will result in the stored config being deleted every time the SDK starts up aka Kits et al we will behave like it's a fresh install every time
  - setting it to an Integer greater than 100 will trigger a warning-level log message reminding the client that the time unit is days, but still proceed with the value
• setting it to a reasonable (<100) Integer will set that value as the config max-age in days seconds

Internal Behavior

• we will check config age exactly once per app start in the ConfigManager constructor

although it is possible the ConfigManager may get called at other points in our code, no where else will it pass in a configMaxAge, so in those cases it would default to null/do nothing

• staleness is determined by ("config timestamp" + "Milliseconds in a day" * configMaxAge) < System.currentTimeMillisso there is no rounding or anything, the config will be invalid
• when a config is "deleted" for staleness reasons, we will also delete the stored ETag and stored If-Modified values.

Testing Plan

• unit tests for MParticleOptions and ConfigManager
• integration tests for maxConfigAge == 0 and "maxConfigAge not set" where we 1) start the SDK 2) wait for config to load 3) stop SDK 4) restart SDK 5) check stored config before the new one is fetched
• integration test for maxConfig == (big #) and make sure it isn't deleted before it should
• new listener in ComfigManager that will callback when a config is "loaded" and also indicate whether it was a "reload" or a new config...needed this so we had something to actually wait on when refreshing the config in test

//TODO
- mock time and add an integration test for maxConfig == (some number), change the internal time and verify it gets properly deleted

Master Issue

Closes https://mparticle.tpondemand.com/RestUI/Board.aspx#page=board/4842431717611364328&appConfig=eyJhY2lkIjoiMjM4RjY2OUU2RkYxNzFCMTVCMUU5Q0JCRDlFQzQyRTAifQ==&boardPopup=bug/71594/silent

[samdozor]

I like moving the responsibility to persist these here. That said - there is a slight behavior change in that we used to check if they were null. This might be better - whereby if they are null we will pass null into putString below - but then we will also get null back out whereas behavior maybe we wouldn't have? Is there any concern when these are null?

[willpassidomo]

thats a good call-out, it is a change in existing behavior. When I came across the previous logic, it looked like a bug to me, although not a particularly bad one. If we fetch "config1" which returns with "etag1", then the next time around we fetch "config2" which returns without an etag, on the next request we will be using the stale "etag1" in our request header which may lead the server to believe our config is stale-er than it actually is. Net-net, the way I read it, the previous behavior may lead to us fetching more configs than we need too (the extra should have been 304s).

That said, I don't see any concern over this change. Sans any comments or notes on some unexpected behavior we were accounting for when we originally implemented this, this new version seems more "correct"

fixed :)

[mparticle-automation]

🎉 This PR is included in version 5.34.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀