Refactoring the FirebaseAuth Token Verification

[hiranya911]

The implementation of FirebaseAuth for the most part is a monolith without clear separation of concerns. It is currently tightly coupled with the FirebaseTokenFactory, FirebaseTokenVerifier and FirebaseUserManager concrete classes. Because of this it is difficult to make changes to the individual helper classes, and also it is difficult to properly unit test the FirebaseAuth API surface. This is evident from the lack of test coverage in the following classes/packages:

• com.google.firebase.auth 86.48%
• FirebaseAuth 69%
• FirebaseToken 49%
• FirebaseUserManager 89%

This is the first of a series of refactorings I've planned in order to make the implementation more modular and more testable. In this PR I'm mostly focusing on the token verification logic, while keeping user management and custom token creation intact. The key changes include:

1. FirebaseTokenVerifier is now an interface. This dependency is injected into the FirebaseAuth via a a builder. This makes it possible to test all token verification APIs by using a mock FirebaseTokenVerifier in unit tests.
2. FirebaseTokenVerifierImpl class provides the default implementation of FirebaseTokenVerifier. All uses of the IdToken API are handled by this class as implementation details. This encapsulation enables us to easily change how we parse/verify ID tokens in the future (if the need ever arises).
3. Token revocation checks are implemented as a separate implementation of the FirebaseTokenVerifier interface, and engaged as needed via the decorator pattern.
4. FirebaseToken implementation has been decoupled from the Google API client's IdToken implementation.
5. Using the Guava Supplier<T> interface to inject token verifier dependencies into FirebaseAuth. In addition to dependency injection, this provides us an elegant way to implement lazy loading as well.
6. Increased unit test coverage.

Test coverage numbers after this change:

• com.google.firebase.auth 92.31%
• FirebaseAuth 80% (we can cover the rest when we refactor token creation and user mgt)
• FirebaseToken 100%
• FirebaseUserManager 89% (unchanged in this PR)

[hiranya911]

Resolves #65

[ashwinraghav]

Can continue being final ?

[hiranya911]

Done

[ashwinraghav]

I see some more variables in here that can be finalized. Can we change across the board?

[hiranya911]

Thanks @ashwinraghav. I've addressed your comments. Please take a look.

[ashwinraghav]

Minor Nit. Otherwise LGTM

[hiranya911]

Lot of these methods used to have anonymous inner classes that wrap the arguments. Which is why they are marked final in most cases. But this is no longer the case. In any case, I've made the arguments to all private helper methods final.