Next Phase of migrating Profile to React

[Abby-Wheelis]

Before the Profile and accompanying popups, pages, etc are 100% migrated, I'm going to pivot focus to the Dashboard screen so that once it is in React, we can start to move from angular to React routing. Next steps when I return to the Profile migration to include:

• converting the privacy policy to a React element - this will be one of the few pieces left in angular, and will need to be converted into React - this can also include an adaptation of the internationalization of the file, as it is currently an html file for each language that also reads from the dynamic config. For more streamlined translations we could turn to a key for each paragraph
• converting the "log" pages to React - these pages are accessed from the dev zone and they have not begun to be converted yet. A "FlashList" or "FlatList" can be used to display the logs as a replacement for "infinite scroll" in the old framework. "FlatList" is easier to use, but "FlashList" performs better so I think I should try "FlashList" but potentially fall back on "FlatList" since developers are really the only users of those elements, so performance isn't of the highest priority. After conversion, React routing can be used to access those pages
• support "dumping json" for a range of dates rather than a single date, which will require adapting the function that generates the file. Supporting a range selection is easy with the implementation of ReactNativePaper's datepicker

[Abby-Wheelis]

Other things to address in the next pass:

• improve accessibility - see comment
• consider visual distinction in config vs translate text in PrivacyPolicy for development
• based on feedback, adjust handling of Samsung phones in AppStatus

[Abby-Wheelis]

More future changes and feedback from: Migration of Profile Logic #1009

support "dumping json" for a range of dates rather than a single date

note that the amount of data that can be downloaded depends on the amount of memory available on the users' phone

From review, if we do change this we have to be aware that overloading will crash the app

Future changes from review comments:

• consider only supporting the copy opcode text button on dev builds
• privacy policy to be used across onboarding and profile, so the text should be a separate component from the container
• set min date of the date picker to start month from dynamic config (instead of hardcoded 2015!)
• we might want to ensure that all configs have the raw_data_use and then remove this backwards compat hack default_raw_data_use in ProfileSettings.jsx
• also remove backwards compat hack for app_required and opcode see comment
• remove consent "number" and redesign handling of changing terms and conditions in the middle of a collection period see comment
• move app version to somewhere more visible than the developer zone (maybe general?)

@shankari for visibility of where I'm tracking the "future" comments

[Abby-Wheelis]

More changes, this time from Profile changes to unblock routing

This is fine for now, but I am not sure that we actually need this going forward. As you can see, this was from a request from the first program to use OpenPATH (CCI Berkeley, in 2017), that wanted to ensure that people synced the code when the program was complete. #266
We have not had that request recently, and the admin dashboard, which shows the last sync might also help with this. When we resolve the native code issues identified, we should also revisit the need for, and the implementation of, the force sync mechanism.

• re-evaluate forceSync, and how it is handled

this is fine for now and I am not going to hold up the merge for this, but I do think that having more of a dynamic "popup style" AlertBar, as outlined in
e-mission/e-mission-phone#1029 (comment) would be beneficial for the long-term instead of having a bunch of hidden alerts.

• universalized "Alert" now that we have some React routing, to disentangle some of the web of shown/hidden elements