[Android] Synchronize content retrieval over the bridge

[mkevins]

Related PRs:

gutenberg-mobile: wordpress-mobile/gutenberg-mobile#4182
WordPress-Android: wordpress-mobile/WordPress-Android#15508

Description

This synchronizes the content retrieval mechanism for serializing content from the editor, and includes title and content in a single event.

Both getTitle and getContent utilize the same mechanism to retrieve data from the editor within the JS runtime: and event is emitted, and a countdown latch awaits the response on the thread that emitted the event. Since this can be invoked concurrently, a race condition currently exists when serialization time is sufficiently long and a second instantiation of a countdown latch overwrites the latch awaited on an earlier thread. By synchronizing access to the latch, we can prevent overwriting of the latch and resolve the race condition.

Since both of these methods each result in the same response (including both the title and the content), we also combine them into a single event.

The access to the latch is also synchronized in the triggerGetContentInfo which relies on the same mechanism (and event).

How has this been tested?

This has been tested by opening a large post and logging the concurrent jobs triggered by the autosave mechanism as well as user initiated save events, and ensuring that the content saved represents the latest state of the UI (the source of truth).

Steps

1. Create a post (easier on web) with this content pasted into the code editor
2. Save the post on web and close it
3. Open the post on mobile and make some changes
4. Test the following flows
   1. Allow autosave to occur (after waiting more than 500 milliseconds between edits)
   2. Manually save the post
   3. Exit the editor with autosave queued up (the large post will take several seconds to save)

None of the above scenarios should result in a crash.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[mkevins]

I believe that the intent of the get content timeout callback is not achieved by the current code. I think that onGetContentTimeout was meant to be called when the latch await timeout is exceeded, however, await does not throw in this case. Instead, it merely returns false. I believe this logic should be refactored, or at least renamed, since the current naming is misleading, imo. Also, it may be beneficial to log the cases where the timeout is indeed reached (when await returns false), which I think was the original intent.

[mkevins]

I've updated this with bc2ab62 👍

[mkevins]

I've added more logging, and addressed a few "TODO" items.

[antonis]

Great work @mkevins 👍
I tested this on a Pixel 5 (Android 12) and everything worked as expected in my tests. The code changes also look consistent to me 🎉

[mkevins]

Thank you for reviewing and testing!