Improve IdpResponse error handling for auth sign-in

[aviadmini]

Would be great to get original error codes (like these) to get more flexibility in error resolution.

Also possibly move constants from ErrorCodes to IdpResponse itself (and annotate with @IntDef ?)

[samtstern]

@aviadmini one of the goals of this library is to hide the underlying errors from all of the different auth APIs that we use under the hood. So exposing all error messages would be somewhat counterproductive.

Is there a specific error case you had in mind that we're not handling properly?

[aviadmini]

@samtstern totally makes sense, it definitely shouldn't be primary way of error resolution

In my case I'd like to both have all the login logic solved in FUI auth activity and then in case of specific error codes like INTERNAL_ERROR I'd like to retry automatically/show specific error message. I actually get this error more often than expected.

Actually it might be a good idea to catch this particular one in FUI and make a retry. For me it always succeeded login after INTERNAL_ERROR was returned (well, not exactly returned, but shown in logcat)

[samtstern]

@aviadmini thanks for the clarification, that's very interesting. Do you know under what conditions you get INTERNAL_ERROR?

[aviadmini]

Unfortunately it seems to be random. Although I'm doing a lot of login-logout cycles with different constraints. Potentially it could mess up things

[SUPERCILEX]

@aviadmini How would you use the different error codes? I have a solution in mind, but I'm having trouble seeing the end value to the dev once they receive a more detailed error...

Here's my proposed solution:
Error codes are kinda messy and they are limited in the amount of information they can provide. Instead, I was thinking of returning a custom Exception with a detailed error message. I can already think of a few main categories:

1. MisconfiguredProviderException: here, here
2. UserCancellationException: here and here
3. UnknownErrorException: here, here, and here
4. In some cases, we can return the original exception directly: here

There are probably a few other cases I missed, but the idea would be to return an exception with a detailed error message that the dev could act upon. Adding a MisconfiguredProviderException could possibly resolve #341 too. As for implementation, turns out exceptions implements Serializable so passing them around in Intents should work just fine.

However, as @samtstern said, FirebaseUI tries to handle all the exceptions for you so I'm not sure if we want to go the detailed error route.

[SUPERCILEX]

Hmmm, I just realized returning the original exception would make things messy. Instead, we could provide a wrapper exception around the original one.

[niqo01]

Hello @samtstern @SUPERCILEX, I would expect from the this library to handle itself all errors, and provides a way to log those for analytics purpose. For example I don't expect ErrorCodes.NO_NETWORKand would prefer that the library shows a snackbar with a retry button.
I would also like to see on the AuthUi a method like setListener(listener)

  /** Callbacks for AuthUi events. */
  public interface Listener {
    /**
     * Invoked when an auth related operation has failed. This is useful for reporting auth failures to a
     * remote analytics service, for example.
     */
    void onException(Exception exception);
  }