Use Firebase for analytics reporting

[pkalita-lbl]

Fixes #132

Summary

These changes introduce the Firebase native (iOS and Android) and web SDKs via a Capacitor plugin. This allows a number of events to be automatically collected, and allows us to collect our own custom events.

There are actually two separate Firebase projects and corresponding configurations: one for development and one for production. Because of that there are some changes here aimed at making our dev-vs-prod split more explicit.

Details

New dependency

These changes use @capacitor-firebase/analytics as a way to hook into the Firebase native SDKs. I initially used the @capacitor-community/firebase-analytics package however I found it to be a bit buggy, and it seemed to be less actively maintained.

Dev and Prod Environments

The overarching goal here is that we want to be able to develop code that sends analytics events and ensure that code works as expected (both now and in the future) without having that development work contribute to the analytics data that will be used for actual usage reporting. Firebase explicitly recommends using separate Firebase projects for this use case. Their documentation also gives some helpful pointers on how to configure native iOS and Android projects to point to different Firebase configuration files. It boils down to having two iOS schemes or targets (our's are called App and App_Prod) and two Android flavors (our's are called dev and prod). Since our native projects are managed by Capacitor, I also consulted this guide from the Capacitor docs on how to use multiple environments. That resulted in a number of changes to files in the native project directories, but overall those changes should be pretty transparent for day-to-day development.

A few things I'll point out specifically:

• I renamed the sim.android and sim.ios NPM scripts to dev.android and dev.ios. This is to emphasize that they will be using the development configurations.
• It shouldn't matter for most things, but I'll point out that when running with the development configuration the app ID is now org.microbiomedata.fieldnotes.dev. The production configuration will continue to use org.microbiomedata.fieldnotes.
• The actual native Firebase configuration files are named google-services.json for Android and GoogleService-Info.plist for iOS. They can be redownloaded from the Firebase console at any time. Since the native SDKs identify these files by name they have to get stored within separate folders within the native project structures. This is outlined in the Firebase docs.

Analytics off by default for dev

Firebase is globally enabled or disabled at initialization time based on a new configuration variable called ENABLE_FIREBASE_ANALYTICS (set via an environment variable called VITE_ENABLE_FIREBASE_ANALYTICS). This must be explicitly set to true in order for Firebase to be enabled, as in .env.production. Only if you are actively developing code that sends analytics events would you need to include this variable in your .env.local file. Otherwise it is fine to omit it or explicitly set it to false.

Custom analytics events

• All custom analytics events are managed by functions exported from a new module, src/analytics.ts.
• Since our app is essentially a single-page application, the built-in automatic collection of screen views doesn't give us anything meaningful. I added src/AnalyticsScreenViewListener.tsx as a way to listen to navigation changes in the React router and manually set the current screen there. In other words we are following the recommendations in the "Disable screenview tracking" and "Manually track screens" sections here: https://firebase.google.com/docs/analytics/screenviews)
• When a user logs in or logs out we set or clear the user ID associated with future analytics events.
• Other custom events are pretty straightforward and happen when a user successfully creates, updates, or deletes a study or a sample within a study. I think that'll be sufficient to answer the general questions outlined in this comment, but I'm also open to suggestions for additional events.

[eecavanna]

Awesome! Thank you for implementing this; and for including that PR description, which, as usual, I found helpful as a primer for reviewing the diff.

Other than a couple comments about typos in documentation, I think all the comments I left were notes to myself.

As long as including the "API keys" in the repo is intentional (doing it any other way may not be practical), I'd be OK with this being merged in as is.