Add new smoke tests (Firestore)

[allisonbm92]

This pull request adds a new smoke test for Firestore and some infrastructure for the other smoke tests that be added soon. This pull request replaces #296.

The infrastructure is a little rough at this point, but it will be improved by the time we ask other developers to write their own tests.

[ashwinraghav]

Thinking out loud.

Objectives / Design Goals

1. Test the release infrastructure by testing released artifacts- proguard.txt, desugar.
2. Test compatibility across SDKs and API boundaries.
3. Have test code and testable code sit side by side.
4. Run test code and testable code in test and app threads respectively.
5. Package test code and testable code into test and app APK respectively.
6. Test our products along with AGP's app extension (as opposed to library extension)
7. Report meaningful SDK error instead of (say) "View could not be fond on screen".

---

Change #296

Pros

• Test code was located side by side with code to be tested (referring to this as testable code henceforth).
• Test code and testable code were packaged into corresponding, correct APKs.
• Test code was run in the test thread. Testable code in the main thread.

Cons

• Product teams are required to learn the channel APIs.
• Nit: Channel APIs were fluent when it came to our tasks based APIs. But not otherwise.

  firebase-android-sdk/smoke-tests/src/androidTestDatabase/java/com/google/firebase/testing/database/DatabaseTest.java

  Line 39 in 370f2a5

  FirebaseAuth auth = FirebaseAuth.getInstance();

• In theory, these APIs would have to be evolved with the underlying APIs of the products.
• The design goal of having channel APIs report the underlying SDK error instead of (say) "View could not be fond on screen" might be quite hard once we start proguarding.

---

Change #319

Pros

• No new APIs need to be understood / maintained.

Cons

• We have substituted the learning curve of the API with the unconventional pattern. Unconventional because:
  • Test libraries are in packaged the app APK.
  • App Code is being run on the test thread.
  • Nit: When we proguard these, we would have to preserve the @SmokeTest annotations.
  • Much like Add new smoke tests #296 , once we proguard, the usability of test results does reduce. This seems inevitable at this point.

---

With either of these solutions, there is a significant underlying design decision that the Android Test Frameworks team made, that we are violating by design.

For #296, all code is in the test APK, for the sake of colocation.
For #319, test code is in the app APK (for the sake of colocation) and firebase is run on the test thread to avoid the channels API.

I feel like colocating test code and testable code (3) is not valuable enough for us to be jumping through hoops in both solutions.

7 seems hard after proguarding.

It still seems to me like achieving 1,2,4,5 will be great value and we can do this without UI, by publishing intents to apps and getting back intents from apps.

If we decide to prioritize other goals, we should talk to the Android Frameworks team and get them to explicitly sign off on their design choices that we are explicitly overriding.

[google-oss-bot]

@allisonbm92: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
connected-check-changed	da1ac2e	link	/test connected-check-changed

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.