[SDK-342] - AuthRetry logic

[Ayyanchira]

🔹 Jira Ticket(s) if any

• SDK-342

✏️ Description

Adds automatic JWT retry for offline-queued requests. When a stored offline task receives a 401 JWT error, instead of retrying inline, the task is retained in the DB and task processing pauses until a fresh token is obtained.

Changes by file

IterableApi.java

• Reads autoRetry flag from remote configuration and persists it in SharedPreferences.
• Exposes package-private isAutoRetryOnJwtFailure() for internal use only (not customer-facing).

IterableAuthManager.java

• Introduces AuthState enum (VALID, INVALID, UNKNOWN) to represent JWT token health.
• Adds AuthTokenReadyListener pub/sub so components (e.g., IterableTaskRunner) can react when a new token is available.
• handleAuthTokenSuccess sets state to UNKNOWN (new token, not yet verified); setIsLastAuthTokenValid(true) transitions to VALID.
• State transitions from INVALID → non-INVALID notify listeners to resume processing.

IterableTaskRunner.java

• Implements AuthTokenReadyListener. On JWT 401, marks auth INVALID, pauses processing, and returns RETRY without deleting the task.
• On onAuthTokenReady() callback, resumes task processing with the fresh token.
• Always uses the current live auth token (via authTokenOverride in fromJSON) instead of the stale one stored in the DB at queue time.

IterableRequestTask.java

• When autoRetry is enabled and the request is offline, skips inline retry and schedules a delayed auth token refresh instead — IterableTaskRunner handles the retry.
• Defensive null-check on getErrorStream() and responseCode >= 0 guard against network inspector interference returning -1.
• Heuristic: if responseCode == -1 but response body contains JWT error codes, infers 401.
• fromJSON overload accepts optional authTokenOverride for injecting fresh tokens into deserialized offline tasks.

OfflineRequestProcessor.java

• Registers taskRunner as AuthTokenReadyListener on construction.
• dispose() method unregisters the listener to prevent stale accumulation when offline mode is toggled.

IterableApiClient.java

• Calls dispose() on the old OfflineRequestProcessor before replacing it in setOfflineProcessingEnabled().

Resolved concerns from earlier draft

• IterableConfig.autoRetryOnJwtFailure should not be customer-facing → Removed from IterableConfig (commit be05ccb). Flag is now remote-config only.
• fromJSON authTokenOverride purpose unclear → Used by TaskRunner.processTask() to inject fresh token into stale DB tasks. Correct architectural choice (task-management concern belongs in TaskRunner, not RequestTask).
• isJwtFailure method redundant? → Kept as a small, well-named abstraction. In offline context, any 401 is treated as JWT failure since the API key was valid at queue time.
• responseCode -1 handling → Defensive heuristic kept. Null errorStream check is valid per Android HttpURLConnection docs.

⚠️ Known issue discovered during testing (pre-existing, not introduced by this PR)

registerDeviceToken is called repeatedly on every JWT rotation.

setAuthToken() calls completeUserLogin() whenever the token string changes. completeUserLogin() unconditionally calls registerForPush(), syncInApp(), and syncMessages(). This means every JWT refresh (e.g. on expiration) triggers a full re-registration cycle even though the user identity (email/userId) and push token (FCM) haven't changed.

completeUserLogin was designed for user identity changes (setEmail/setUserId), where re-registering makes sense. But setAuthToken also triggers it on routine JWT rotation, causing unnecessary API calls. setAuthToken should distinguish between "new user login" and "credential refresh" to avoid redundant work.

Needs a separate ticket to address.

[Ayyanchira]

Self review until OfflienRequestProcessor.java