fix(ios): prevents post-restore kbd issues by refreshing kbd

[jahorton]

Fixes #6542. Fixes #2184.

This fixes a longstanding behavior we've noted on certain iOS devices where our keyboards and/or predictive text become "unstable" in one manner or another after the Keyman app has been restored from a backgrounded state. While not the most elegant of solutions (it has user-perceivable effects), simply refreshing the keyboard host page will remove that "instability".

My personal device has always been affected in one way or another when restoring the Keyman app from the background, though the manner has varied at times. Either way, I'm aiming to finally get that fixed.

[keymanapp-test-bot[bot]]

User Test Results

Test specification and instructions

• ✅ TEST_IOS_APP_RESTORE (PASSED): Tested with the attached PR build (Keyman 17.0.305-beta-test-10952) on an iPhone 13 Mobile device (iOS 17.4) and here is my observation: 1. In the default keyboard, verified that the longpress mend and selecting the sub key is working as expected. 2. Confirmed that the downward flick gesture displayed the special characters.. 3. Verified the multitap on the numeric key to change layers is working correctly. 4. Verified holding a layer-switching key and typing with the temporarily-active layer is working as expected.

Test Artifacts

• iOS
  • Keyman for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image)
  • TestFlight internal PR build version - 17.0.305 (0.10952.10730)

[bharanidharanj]

Test Results

• TEST_IOS_APP_RESTORE (PASSED): Tested with the attached PR build (Keyman 17.0.305-beta-test-10952) on an iPhone 13 Mobile device (iOS 17.4) and here is my observation: 1. In the default keyboard, verified that the longpress mend and selecting the sub key is working as expected. 2. Confirmed that the downward flick gesture displayed the special characters.. 3. Verified the multitap on the numeric key to change layers is working correctly. 4. Verified holding a layer-switching key and typing with the temporarily-active layer is working as expected.

[jahorton]

After a bit more searching... maybe I've found something this time?

• https://developer.apple.com/documentation/webkit/wknavigationdelegate/1455639-webviewwebcontentprocessdidtermi

We'd need to test and see if this is being called when our app is restored in this scenarios to be sure it's tied to the behavior that's been seen, of course.

Ref: https://github.com/ionic-team/capacitor/discussions/5488#Potential_solution

The thing we need to be sensitive to is that when a WebView background termination occurs, webViewWebContentProcessDidTerminate() is invoked when the app is coming back into the foreground [...]

Noting other issues from ionic and from react, they've seen cases where the WebView is 100% crashed, showing a blank page. We haven't had that issue, though we also aren't navigating across pages or doing other fancy web-server stuff on the back-end - it's just one page for us... albeit with a WebWorker backend and linked-in JS scripts. There's a fair shot that iOS's WebView is doing its best to restore our page after such a termination but is coming up short.

• Example react issue: https://github.com/react-native-webview/react-native-webview/issues/3062

One concerning thing here, though - these are big teams that are struggling to get this scenario right if this is indeed a match for our circumstances.

[keyman-server]

Changes in this pull request will be available for download in Keyman version 17.0.311-beta