feat(Runtime): Allow rollout cancellation and simplify decision logic

[floydkim]

related PR

• feat(Runtime): Add Rollout Percentage functionality #81

feat(Runtime): enhance rollout feature

• Integrate the rollout check into the existing version check logic to improve cohesion and allow rollout cancellation
• Prevent potential issues where a pending update might not proceed due to the latest update being a rollout target (scenario expected to be rare)

refactor: simplify rollout decision logic

• The original logic cached decisions to reduce recomputation cost and ensure consistent results when the app version and rollout percentage were the same
• Rollout determination uses a hashed value of the client ID, which CodePush stores using SharedPreferences or UserDefaults
• The client ID can change if the app is uninstalled or its storage is cleared; the cache is also removed in such cases, so the lifecycle of the client ID and the cache are effectively the same
• Therefore, even without caching, determining rollout status on every update check can still guarantee the same results (with the aforementioned constraints)
• The hashing logic also appears lightweight enough to avoid any performance issues

[floydkim]

Hello, @chiraag918 !
While refactoring the code you contributed, I ended up making two changes which are noted in the PR description.

First, I modified the rollout-related logic so that it integrates better with the existing logic and now allows rollout assignments to be canceled.

I thought that the existing logic for finding and applying the latest version in the release history and the newly added rollout logic were conceptually closely related but implemented separately in the code.
Unfortunately, I didn’t realize this when reviewing the PR.
After trying several approaches, I consolidated the logic, which allowed me to add a few rollout-related test cases to the existing unit tests.
Documentation is still insufficient to clearly explain the behavior, but I belive it’s better than having none 😭.

Second, I removed rollout decision caching and the Storage module.

I found that the clientUniqueId generated by CodePush can be reset if the app is re-installed or its storage is cleared, because it is stored using SharedPreferences or UserDefaults.
I also thought that since the bucket assignment logic is deterministic, the assignment result would always be the same as long as the client unique ID does not change.
I hope the PR description provides enough explanation, but please feel free to let me know if you have any concerns or questions.

[chiraag918]

@floydkim I went through the code, looks cleaner when compared to my version. Yes, I missed integrating it with the version check logic 😣, thanks for fixing it 🫡.

And regarding the rollout cache being, I understand your concern, ig, taking it down, keeps the logic simple and also no dependency on storage interaction.

[floydkim]

@chiraag918
Thank you for taking the time to give feedback!
Then I'll release a new version soon. Once again, thank you for your contribution.