Decouple TextToolbarStatus from iOS context menu visibility

[Vladimir Mazunin (mazunin-v-jb)]

Decouple TextToolbarStatus from the native context menu on iOS visibility to fix leaks and incorrect behavior.
Clean ups in the UIKitTextInputService.ios.kt

Since the TextToolbar.status was tied with isEditingMenuShow flag, during back navigation there might be cases when TextToolbar.status reports as Hidden while the menu repositioning is happening on the CMPEditMenuView side.
That's why SelectionManager doesn't call TextToolbar.hide() (as it should during the back-navigating teardown), and the menu reappears once again, leaking the ComposeTextInputView in the view hierarchy.

Fixes: CMP-9316 [ios]. context menu doesn't hide after backNavigation

Testing

Should be tested by QA, the case in the attached task

Release Notes

Fixes - iOS

• Fix the context menu lingering on screen after navigating back from a SelectionContainer

[Andrei Salavei (ASalavei)]

Just in case: we propagated isEditMenuShown because the edit menu can hide by itself (for instance when user taps outside the context menu) - in this case it's highly possible to have misaligned status: TextToolbarStatus with the real visibility of the context menu.

Please verify it won't be an issue in the standard use-case, like operating with Text Fields.

[Vladimir Mazunin (mazunin-v-jb)]

in this case it's highly possible to have misaligned status: TextToolbarStatus with the real visibility of the context menu.

Yes, I've found a regression after textfields retesting unfortunately
Not sure if this is the root cause for the issue though
Investigating, changed it to the draft

[Vladimir Mazunin (mazunin-v-jb)]

Looks like the regression isn't caused by changes here.
But I'll keep this in a draft until it is fixed