feat(expo)!: drop expo-error-recovery

[EvanBacon]

Why

• expo-error-recovery does not appear to be used anymore with EAS Build / expo-updates. Looks we just used it in Expo Go and shell apps
• We previously required this module because there was no ability to install native crash reporting libraries like crashlytics.
• expo-updates appears to have implemented a different version of error-recovery here.

If we want functionality like this, I propose we implement it as an unexposed feature of expo-updates which reports to EAS Update as a type of analytic service. Users who want similar functionality without EAS can use a different native error reporting package with dev clients.

How

This PR simply removes error-recovery from expo, if the proposal is accepted then we'll need to update docs, deprecate the package, and remove code from Expo Go.

[tsapeta]

Looks good to me, requesting @lukmccall for review as he might have some input too.

[lukmccall]

LGTM and I'm okay with that change ;)

[ide]

Archaeology

I found the very first commit that documented ErrorRecovery:

Expo can also report custom information back to you after your app reloads. If you use ErrorRecovery.setRecoveryProps, and the app later encounters a fatal JS error, the contents of that method call will be passed back into your app's initial props upon reloading. See Expo.ErrorRecovery.

Expo.ErrorRecovery.setRecoveryProps(props)

Set arbitrary error recovery props. If your project crashes in production as a result of a fatal JS error, Expo will reload your project. If you've set these props, they'll be passed to your reloaded project's initial props under exp.errorRecovery. Read more about error handling with Expo.

It looks like there were two behaviors described here:

1. The Expo runtime would automatically catch fatal JS errors and reload the app, preventing the app from crashing at the OS level.
2. You could detect when this happened because your root component would be passed your ErrorRecovery props.

Today

AFAIK we do not automatically reload upon fatal JS errors in most cases. There is one explicit exception, which is when expo-updates launches a new update for the first time and a fatal error occurs early on in the launch process (until right after the root view is initially mounted IIRC).

One thing ErrorRecovery does that expo-updates does not AFAICT is tell the developer when an automatic reload happens. expo-updates has Updates.isEmergencyLaunch, which describes something different (this is when we need to launch an older update, which is dangerous if the last update was backwards-incompatible, and hence used only for emergencies). Will add this as a discussion topic at next week's expo-updates meeting.

Meanwhile, given that automatic reloading happens only in Expo Go and apps made with the Classic Build service which is ending at the start of next year, I have no pragmatic objections to removing ErrorRecovery.