`OSConsistencyManager` & IAM fetch read-your-write consistency implementation

[rgomezp]

Description

One Line Summary

Introduce and integrate a ConsistencyManager to manage read-your-write tokens for improved segment membership calculation.

Details

Motivation

This update introduces the ConsistencyManager to manage RYW tokens. The goal is to improve the accuracy of segment membership calculations by providing an open-ended & highly customizable blocking mechanism for operations that rely on having successfully synchronized client & server state.

For a first use-case, we want to block the fetching of IAMs until we have tokens for a user or subscription state update.

Scope

• OSConsistencyManager implementation
• Updates the Subscription and User backend services to return offsets needed by the OSConsistencyManager.
• Modifies Subscription and UpdateUser operation executors to set tokens in the OSConsistencyManager.
• Updates the OSMessagingController to delay IAM fetch until the token is available. Implements the retry logic.

Testing

Unit testing

• New coverage for new ConsistencyManager class

Manual Testing

• Set up iOS test app in OneSignal
• Note the current app version (e.g. 1.0)
• Create a segment targeting a specific version (e.g. 1.1)
• Create an in-app using the new segment
• Open the app (see you don't get an in-app)
• Close the app
• Change the version to the one in the segment (e.g. 1.1)
• Open the app (see you get the in-app)

Affected code checklist

• [ ] Notifications
  • [ ] Display
  • [ ] Open
  • [ ] Push Processing
  • [ ] Confirm Deliveries
• [ ] Outcomes
• [ ] Sessions
• [x] In-App Messaging
• [x] REST API requests
• [ ] Public API changes

Checklist

Overview

• [x] I have filled out all REQUIRED sections above
• [x] 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

• [x] I have included test coverage for these changes, or explained why they are not needed
• [x] All automated tests pass, or I explained why that is not possible
• [x] 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.
• [x] 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