[expo-updates][ios] add more database fields for error recovery manager

[esamelson]

Why

ENG-1493

#14397 (comment)

How

Add the following database fields to updates:

• successful_launch_count -- how many times the update has launched and we've successfully received RCTContentDidAppearNotification. Once this is > 0 we want to mark all older updates as outdated and will no longer fall back to an older update. [This could be a boolean field, but since booleans are integers in SQLite anyway I thought it could be useful in the future to keep track of the number of launches 🤷 ]
• failed_launch_count -- how many times the update has failed to launch, i.e. thrown an error before the initial render. Once this is > 0 we won't try to launch the update again, and we might fall back to an older update if a newer one isn't available. [again, could be a boolean]
• is_outdated -- whether or not a "newer" (determined by selection policy) update has been launched successfully. If this is true we won't launch the update again. (It might still be kept around for its assets, to make server-based rollbacks quicker.)

Test Plan

Tested as part of the full PR stack

Todo

Once this PR stack is finalized, write the full DB migration

Checklist

• Documentation is up to date to reflect these changes (eg: https://docs.expo.io and README.md).
• This diff will work correctly for expo build (eg: updated @expo/xdl).
• This diff will work correctly for expo prebuild & EAS Build (eg: updated a module plugin).

[jkhales]

Is it possible that we can get by with just one new "boolean" field?

[jkhales]

If an update has a failed_launch_count > 0 then how is it possible to ever gain a succesful_launch_count > 0?

If this is not possible, than can't we just monitor the failed_launch_count?

[ide]

An update can inconsistently succeed or fail e.g. it could succeed the first time and fail the second (successes = 1, failures = 1). This check is to see if the update has ever been successful or if it has never run at all. Another way to read this check is successful_launch_count > 0 OR successful_launch_count + failed_launch_count = 0.

[jkhales]

I see, thanks. Still feels like there is a way we could condense these columns, but maybe that more of a personal stylistic choice.

[jkhales]

I'm curious why we just don't call markUpdatesOutdated where ever this is used instead?

And get rid of the successful_launch_count column?

[ide]

The is_outdated column might be a duplicate source of truth -- if an update in the database has successful_launch_count > 0, aren't all older updates that target the same RTV outdated? Seems better to run the query (plus it's a small table anyway) instead of adding a column.

[esamelson]

The is_outdated column is a duplicate source of truth as long as the following assumptions hold:

• once an update has run successfully, nothing will prevent expo-updates from running it again as long as it's the most up-to-date compatible update
• the selection policy will always choose the most recent compatible update to run
• newer updates will never be deleted before older updates

If we're comfortable that these assumptions will always hold then I'm fine with removing this column; the main reason I added it was to keep track of this data on a per-update basis rather than depending on the existence of other updates to derive it.