Make use of ryw_delay to minimize retries on IAM fetch

[rgomezp]

Description

One Line Summary

Encapsulate rywToken and rywDelay into a RywData class and update usage throughout the codebase including delaying IAM fetch by the specified delay.

Details

Motivation

This update introduces the RywData class to group rywToken and rywDelay into a single data object. This ensures both values are handled together, allowing for accurate delay management based on the most recent rywToken.

Along with ryw_token, ryw_delay is returned by user & subscription create & update endpoints. It essentially says "this is about when we expect the change will be ready". The goal is to minimize retries.

Scope

• Encapsulated rywToken and rywDelay into the new RywData class to centralize their usage.
• Updated method signatures: All previous usages of String (rywToken) are replaced with the new RywData object.
  • Renamed setRywToken method to setRywData to reflect this change.
• IAM fetch logic adjusted: The delay for IAM fetch now leverages the rywDelay value from RywData. A fallback mechanism ensures minimal retries to the backend.
• Renamed methods for clarity, ensuring method names convey when a value is expected to be returned.

Testing

Unit testing

Tests were updated & passed.

Manual testing

Tested accurate segment membership calculation & display of IAMs. e.g:

1. Create two IAMs targeting segments with version 1, & another targeting version 2 of the app
2. Set the IAMs to display every time conditions are met
3. Switch back & forth between versions in the example app
4. See that you get the correct IAM

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 

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208624001324438