In-app browser JS code registered in setTimeout() callback persists in "the background" and executes after in-app browser is closed - iOS only

# Bug Report
I'm experiencing weird behaviour, both on ios emulators and the physical ios devices, where a setTimeout callback created in the in-app browser JS context is running after the in-app browser closes, exactly after the duration of time specified in the setTimeout call.

## Problem
In-app browser JS code registered in setTimeout() callback persists in "the background" and executes after in-app browser is closed

### What is expected to happen?
JS code registered in setTimeout() callback does not execute after in-app browser is closed.

### What does actually happen?
Here are the (possibly unnecessary to describe) details of what is happening:

My team has a Cordova app that talks to our back end API through AJAX, but for one piece of functionality it opens an in-app browser to do something which loads a page we own. That page has a cookie that refers to the same session the Cordova app is using (though we aren't using cookies to store the session ID in the Cordova app, we're using local storage and passing the session ID in HTTP headers). The page loaded in the in-app browser is a page from the desktop browser version of our app. That page has an auto-logout mechanism that sends a request to the backend that invalidates the session after 30 minutes of inactivity (i.e. the timeout is cleared and re-registered on specific user actions). So what we're seeing is that 30 minutes after the in-app browser is closed, a call is made from some ghost/lingering process to the endpoint that invalidates the session. Note that the http call is made by window.location.href = .

This behaviour does not happen on Android emulators or phyiscal devices.

## Information

### Command or Code
To reproduce, create a web page that logs to the console (or performs some observable action) from within a setTimeout callback. From within a Cordova app, visit that page with in-app browser, and close the page (programatically using inAppBrowserRef.close() ). (In our use case the in-app browser is redirected to a few pages and we only call inAppBrowserRef.close() after we detect we're on a certain page, using event.url, but that shouldn't matter).

Note that not all members of my team experience this issue. Some people are able to build an ios app and run on an emulator and a physical device without this lingering background process making a the session-killing http call.

### Environment, Platform, Device
iOS only. Emulator + multiple physical devices.

### Version information

MacOS 10.15.4
Xcode 11.4.1

All Cordova packages + versions we're using:
```
"dependencies": {
"cordova-android": "^8.1.0",
"cordova-ios": "^5.1.1",
"cordova-plugin-appversion": "^1.0.0",
"cordova-plugin-camera": "^4.1.0",
"cordova-plugin-device": "^2.0.3",
"cordova-plugin-dialogs": "^2.0.2",
"cordova-plugin-file": "^6.0.2",
"cordova-plugin-file-transfer": "^1.7.1",
"cordova-plugin-inappbrowser": "git+https://github.com/apache/cordova-plugin-inappbrowser.git",
"cordova-plugin-network-information": "^2.0.2",
"cordova-plugin-splashscreen": "^5.0.3",
"cordova-plugin-statusbar": "^2.4.3",
"cordova-plugin-whitelist": "^1.3.4"
},
```
Note: currently we're using 4.0.0-dev (which is what github master is pointing to at the moment, and what we've been using since https://github.com/apache/cordova-plugin-inappbrowser/issues/492), but we've seen this behaviour with 3.2.0 and 3.1.0.

## Checklist

- [x] I searched for existing GitHub issues
- [x] I updated all Cordova tooling to most recent version
- [x] I included all the necessary information above

Start by reproducing the issue with a page that logs from a setTimeout callback, then close it with inAppBrowserRef.close(). Inspect the iOS InAppBrowser behavior around closing and callback persistence; done means the callback no longer executes after closure on iOS emulators and physical devices.

Written by the indexing model from the issue text.