[SDK-705] IterablePushRegistrationTask as Runnable instead of AsyncTask

[franco-zalamena-iterable]

Summary

Jira: SDK-705

Replaces push registration AsyncTask orchestration with SDK-owned executors while preserving production behavior and rapid login/logout ordering.

Behavior

• Push token acquisition, registration, disable requests, and their retries use a dedicated SDK-owned serial lane.
• A newer register or disable action invalidates stale retries from an earlier action.
• Push client callbacks continue to run on the Android main thread.
• General online API requests retain their existing thread-pool execution path.
• JWT and HTTP 5xx retry behavior remains supported on the push lane.

Compatibility

• No public API is added or changed.
• Test injection uses package-private constructors and interfaces; no VisibleForTesting state is required.
• The final diff adds no deprecated AsyncTask invocation.

Verification

• Complete iterableapi and iterableapi-ui unit suites pass.
• Focused push registration, public-flow integration, and malformed timestamp tests pass.
• Checkstyle, lint, UI assembly, root consumer tests, and Android-test compilation pass.
• The complete 26-test instrumentation suite passes locally on API 28.
• The notification image test now uses a repository fixture instead of an external network asset.
• The standalone sample reaches SDK compilation and then hits its existing Kotlin 1.8 versus 1.9 data-object mismatch.

[franco-zalamena-iterable]

Stack review update after the rebase:

• The ordering concern remains addressed: push actions and their register/disable HTTP submissions use the same dedicated serial push lane.
• Deterministic coverage protects enable-to-disable ordering and prevents stale registration retries after a newer push action.
• The existing review discussion is preserved.
• The remaining deprecated request AsyncTask findings are intentionally removed by stacked SDK-707 rather than duplicating that migration into SDK-705.

Check, BCIT, changelog, Java analysis, and the main build job passed. I have rerun the two failed jobs after confirming their failures were the external notification-image assertion and one instrumentation response timeout.

Ready for another review.

[franco-zalamena-iterable]

Rerun follow-up: the unit job now fails only on the repository-wide external IterableNotificationTest.testNotificationImage assertion. The instrumentation rerun reproduced the lower-stack AsyncTask response timeout in IterableApiResponseTest; that suite passes on SDK-706 once the deep-link lane is separated and passes on SDK-707 after request AsyncTask is removed. The push ordering coverage and BCIT remain green.

[franco-zalamena-iterable]

@rtlsilva SDK-705 is ready for re-review in 8d7e9e3.

The ordering concern is now handled across the complete push flow: registration and disable submissions, HTTP work, 5xx retries, and JWT retries remain on the SDK-owned serial push lane, while newer actions invalidate stale retries. General online requests are restored to their original thread-pool behavior, and push callbacks remain on main.

The previous CodeQL findings were caused by newly added deprecated AsyncTask calls; those additions are gone from the final diff. Focused behavior tests, UI unit tests, static checks, root consumer tests, and Android-test compilation pass. CI is now running on the updated commit.

[rtlsilva]

No new findings. LGTM