Always remove the window when an IAM is dismissed

[Koji23]

Description

One Line Summary

Always remove the window when an IAM is dismissed

Details

If you do any kind of prompt action while having another IAM queued for display with the same trigger the IAM, the IAM can get stuck and prevent clicking on the app beneath it. We can avoid this by ensuring the window is always removed when the IAM is dismissed

Asana Task

https://app.asana.com/0/1198177413178126/1204945334125976/f

Motivation

REQUIRED - Why is this code change being made? Or what is the goal of this PR? Examples: Fixes a specific bug, provides additional logging to debug future issues, feature to allow X.

Customer is complaining that when they open the iOS native payment screen from an IAM button click, the IAM gets stuck and prevents payment.

Scope

RECOMMEND - OPTIONAL - What is intended to be effected. What is known not to change. Example: Notifications are grouped when parameter X is set, not enabled by default.

OPTIONAL - Other

OPTIONAL - Feel free to add any other sections or sub-sections that can explain your PR better.

Testing

Unit testing

OPTIONAL - Explain unit tests added, if not clear in the code.

Manual testing

RECOMMEND - OPTIONAL - Explain what scenarios were tested and the environment.
Example: Tested opening a notification while the app was foregrounded, app build with Android Studio 2020.3 with a fresh install of the OneSignal example app on a Pixel 6 with Android 12.

We've tested trying to dismiss the IAM while simultaneously adding a click name and pausing all IAMs. This can occasionally cause the IAM's view controller to get stuck and it's window will block you from clicking the app underneath

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 

[emawby]

Looks good lets just cleanup the commit history!

[emawby]

It looks like the iOS 9 unit tests are flaky (they succeed when run individually locally for me). I wouldn't worry about the test failure