convert to the GA4 data API

[escattone]

mozilla/sumo#1705

This PR will also resolve the following bugs:
mozilla/sumo#1140
mozilla/sumo#1169

This PR converts our current GA3 API queries to GA4 data API queries.

Please merge https://github.com/mozilla-it/webservices-infra/pull/1949 immediately prior to merging this PR.

Prior to releasing the code in this PR, make sure https://github.com/mozilla-it/webservices-infra/pull/1950 is merged.

Notes

• The work to grant our existing stage and prod GA-specific service accounts access to our new stage and prod GA4 properties and the GA4 data API has already been completed. ✅
• I've already verified the correctness of the RunReportRequest instances for each case by running each of the functions locally using the stage GA-specific service account.
• In general, the code in this PR consumes less memory and database resources than the current implementation. I avoid creating any intermediate data structures where possible and most of the GA4 functions, like pageviews_by_document, are now generator functions.
• The new pageviews_by_document function is much more efficient that its predecessor, for the following reasons:
  • The old version would return many more rows, often hundreds of thousands of rows, mainly because the response could not be limited to just KB article page views -- it would also include KB article edits and discussion views and so on -- but also because if viewed URL's differed in their query parameters, each variation would be a separate row. The new version only returns one row per viewed KB article, so the upper limit is roughly 45K rows which would only happen if every article in every locale was viewed within the time period requested.
  • The old version would make at least 1 database query for each row that was a KB article view -- to get the article's ID -- and so would often make thousands of database queries. The new version makes no database queries at all.
• The old pageview_by_document function, because it used the Document.from_url class method, would sometimes associate the page views of a localized KB article with a different KB article, for example with its parent, if the localized article no longer existed. This is no longer the case. The page views for a KB article of a given locale and slug are now only associated with that exact KB article or nothing at all if the article no longer exists.

[smithellis]

This is so much cleaner overall!. Just a few changes (maybe).

Thanks!

[escattone]

I just tested the new WikiDocumentVisits.reload_period_from_analytics and QuestionVisits.reload_from_analytics commands from this PR on stage and they are smokin' fast! The GA4 data is still in its infancy on stage, so for example the pageviews_by_document function only returns about 1500 rows for the 90-day period of data, and the pageviews_by_question function returns about 1600 rows -- both will return tens of thousands of rows when the data is mature -- but creating new stats for both took a fraction of a second. That's a dramatic change from our current code! We run the WikiDocumentVisits.reload_period_from_analytics function weekly for all periods (7 days, 30 days, 90 days, and one year), and the current code sometimes takes so much time and memory that it fails, and when I tested it months ago, found that it could take hours to complete. That same weekly run with the code in this PR -- assuming fully populated data in GA4, up to a years worth -- will take at most a few seconds. 🎉