Push Notifications Stack: Tech Debt

Description:

We need to clean and modernize our Push Notifications Stack:

1. Push Notifications have, mainly, two aspects: the API that runs when a Push arrives, and the API that runs when the user interacts with a System Alert
2. Before iOS 10, all of it was handled by PushNotificationsManager
3. Standard way to check if the user pressed on a Push Alert has always been applicationState != .background
4. In iOS 10 AAPL introduced UNUserNotificationCenter
5. We've builtInteractiveNotificationsManager to encapsulate handling of Push Notifications with multiple interactions (Like / Approve / Etc)
6. In iOS 13 point (3) stopped being accurate, and has been the source of Issue #14349

Details:

Tech Debt has been increasing, and we've reached a point in which both PushNotificationsManager and InteractiveNotificationsManager call each other.
We must:

• Review all the things
• Drop applicationState usage
• Definitely drop @objc
• Ideally speaking, have 3 classes to deal with the use cases we've got:
  1. Push Registration: Registering / requesting permissions
  2. Push Notification Received: The document arrived. Used by the AppDelegate
  3. Push Notification Pressed: User interaction was detected. Used by UNUserNotificationCenter
• (2) and (3) may need to run the same code in few specific scenarios such as "Push Auth Received" while the app was in foreground, or "Push Auth was pressed".

Start by tracing the calls between PushNotificationsManager and InteractiveNotificationsManager, then inspect their AppDelegate and UNUserNotificationCenter entry points. Map registration, received, and pressed use cases before deciding how the three proposed responsibilities should be separated. Done means the circular calls, applicationState usage, and unnecessary @objc usage are removed while shared foreground/auth scenarios still work.