Import & Export Onyx state reliability issues

[TMisiukiewicz]

Exporting and importing Onyx state features are highly valuable in scenarios such as:

• Troubleshooting bugs caused by inconsistencies in the local Onyx state, which can lead to unexpected errors or unexpected UI behavior
• Measuring and improving performance on accounts experiencing significant slowdowns, as it allows developers to reproduce and analyze performance bottlenecks in a controlled environment.

However, there is significant room for improvement in both features to maximize their potential and ensure reliability. The current issues include the following:

Export

• Masking export data currently does not include multiple sensitive fields, such as last message, phone number or address
• Every email address and message is replaced with ***. While this ensures data anonymity, it also makes it difficult to analyze and reproduce bugs related to participants-related features and possibly impacts reliability when measuring performance, as the simplified masking fails to simulate realistic data structures or payload sizes

Import

• Missing items in key UI elements, such as LHN and Search option lists, which results in broken or incomplete user experience
• Imported states often show inconsistnt option titles compared to original state
• Certain expenses are missing which impacts testing expenses workflows
• When splitting expense on 1:1 chat, the original account is displayed as third participant
• Navigating back to the original state from an opened report screen often triggers errors

All these issues collectively affect the reliability of the export and import features, reducing their effectiveness for debugging and performance optimization tasks. Addressing these problems is crucial for ensuring their value in real-world scenarios.

[TMisiukiewicz]

While recording videos with a fix for proper displaying LHN elements I noticed the Import is broken on iOS. I'll focus on fixing this one first before I open any other PR since it blocks testing on the platform entirely

[TMisiukiewicz]

Found a solution for above error. The react-native-fs library is not maintained anymore for more than 2 years now, and it is expecting NSInteger pointer for both position and length parameters of read function. According to the React Native docs, using NSInteger should be avoided.

So we have a couple of options:

1. Patch the library and switch from using NSInteger to NSNumber
2. Replace the library with it's fork, https://github.com/birdofpreyru/react-native-fs, which is actively maintained and supports new architecture
3. Use react-native-blob-util filesystem that we already have in the codebase. It supports reading files as stream, so i think it should work as well.

From my perspective, the fastest way to unblock us with improvements of the Import feature is using a patch. However the last one sounds reasonable as well. Which one should we follow? We can always go with a patch first as it's a quick one (and I already have it working) and rewrite it to readStream in the future

[mountiny]

If we already use react-native-blob-util in the app and it can be used here too without issues and its maintained, then lets use that instead of patching the unmaintained library.