[FOR PROGRESS, DO NOT MERGE] Rewrite FirebaseUI auth

[SUPERCILEX]

#856, #948, #526, future support for #724 and #661, easier #123 implementation. In addition, every config change bug you can think of that people haven't reported.

cc: @samtstern + another human?

I was going to name this PR something more specific like "Fix all config change bugs," but then I saw the LoC changed... sorry @samtstern! 😊

Intro

Basically, if you try rotating your screen on pre-PR FirebaseUI, either the user is half signed-in but the UI doesn't show it, or we crash, or we just break randomly. To be frank, we suck! For example, rotate the screen after clicking the email sign up button, the user will actually be signed-in, but we're now broken. Click the button again, and we'll say the user already has an existing account. Duh, they just signed up! 😄

If you can't already tell, I'm super excited about this one which is why I'm sharing it early. So far, it just works! Plain and simple, it works. On the emulator, I've been mashing the Ctrl + Left/Right buttons to create config change after config change and we nail the sign in every single time. Every. Single. Time!

Anyway, the post-PR world will be a new era of ultimate stability. 😄

TODO:

• An event flow for progress changes and a ProgressBar under the Toolbar
• Rewrite tests (shouldn't be testing UI, only business logic)
• Add an AuthExcecutor and run all Tasks synchronously
• https://firebase.google.com/docs/reference/android/com/google/firebase/auth/FirebaseAuthUserCollisionException
• Refactor phone auth, it's completely broken
• Move SignInHandler to a service so we can get rid of the static fields? Nope. I'm open to reconsideration, but this seems like a lot of extra work for little benefit.

The Problem

Fundamentally, most architectures assume that data doesn't talk back to UI. If we think of the auth process of signing-in and saving credentials etc. as "data," then we run into a problem: the data now needs to tell the UI to do stuff. This means both the user and the data are going to be fighting for control over the UI and need to somehow stay connected. In pre-PR FirebaseUI, this lead to nightmares where we just kinda gave up and ignored auth results if the user rotated their screen.

The Solution

I've used a mix of an eventbus + Rx model. Basically, all background auth stuff exists independently from the UI. However, since we need to talk to the UI, we use 4 data flow tracks: one for starting an Intent, another for starting a PendingIntent, yet another one for sending IdpResponses back to the UI to decide what to do, and the last one to send activity results. No more forwarding onActivityResult everywhere! 😄

This means setRetainInstance(true) fragments are dead, the memory leak hacks in FacebookProvider and whatnot are dead, the SaveSmartLock fragment is dead, etc.

I was hoping to be able to submit my PR in more bite friendly chunks, but everything was such a mess that it just wasn't possible.

Project structure overview

• AuthViewModelBase and its descendents have access to FirebaseAuth (and only them)
  • SignInHandler manages all sign-in business login from failures to saving credentials to merging accounts etc.
  • SignInKickstarter manages the intro stuff like figuring out where to send users and the opening credential picker
• Providers are now UI only and have their companion ProviderHandlers. For example GoogleSignInHandler manages all the logic for the GoogleApiClient and the Facebook and Twitter ones manage retrieving profile info, etc.

The rest is essentially the same, just forwarding everything to those classes above. I did rewrite the GoogleApiClient managers and error handling.

Potential limitations

The only one I can think of is perhaps callback hell. I'm not sure how to fix that and for now, I just want it to work. However, I really want it done right. So @samtstern and anyone else, if there's anything you think we can do better or another better solution you can think of, please tell me! I want auth to be a solved problem once and for all! 😄

@samtstern Since this is a massive PR, I'm expecting review to possibly take up to a month, so just take your time with it. It's got to be done right. I'll update it with a review of the classes and changes once I finish the TODOs listed above, but for now you can familiarize yourself with it. Enjoy! 😄

[SUPERCILEX]

All the changes left here have been moved to #1253.