Switch `pgb-broker-utils` -> `pittgoogle-client`

[troyraen]

Closes #5

Depends on mwvgroup/pittgoogle-client#19

Changes:

• Refactor main.py (both classifiers) to use pittgoogle-client instead of pgb-broker-utils
• Use python 3.11 (upgraded from python 3.7)
• Generalize variable and function names
• Use lower case to name new resources. Sometimes this is required (e.g., name of Cloud Run module). My preference is to always use lower case for consistency but if others disagree we can discuss. Resources currently in production are left as-is to avoid breaking changes.

Capturing some to-dos:

• [x] add comment to table and topic name in main.py re: how they are constructed under the hood.
• [x] add http endpoint description comment to the actual docstring of index(). make the route more visible.
• [x] make brokerVersion a global variable and make it a pittgoogle-user version not a broker version (temporary solution)
• [x] move the alert publish_time -> datetime transformation to the client side
• [x] ~publish mwvgroup/pittgoogle-client#19 to TestPyPI and test the supernnova module end-to-end~ TestPyPI is not easy to use in the deployed container.
• [x] rebase this branch onto main
• [x] Publish pittgoogle-client to PyPI. Update requirements.txt files in this branch to point to new client version.
• [x] Test.

[troyraen]

I'd like to consider putting all resource names in a yaml file, then updating setup.sh and main.py to read them from the yaml.

Benefits:

• This would eliminate the duplication of resource name definitions -- currently we rely on the creator/user to manually keep these in sync between setup.sh and main.py.
• This could allow us to have a single setup.sh script that works for all modules, and the module creator or end user would not have to touch it. Each module would have its own yaml which would be easier for the creator/user to work with.
• This would allow us to separate the "teardown" (i.e., delete all module resources) portion of setup.sh into its own script which would simplify the logic.

Other thoughts and implementation details to consider:

• setup.sh could use the yq tool to parse the yaml, as is currently done by our broker's consumer.
• I think we'll want to keep the survey name and testid as script arguments so they can easily be set at runtime (deploy time).
• We need to think about cases where the module creator wants to use different resources than are currently being created in setup.sh. For example, maybe they want to use BigTable instead of BigQuery. Perhaps we could expand the number and types of resources created by setup.sh and include logic that skips the creation of a resource if a name for it is not defined in the yaml.

If we go forward with this it should probably be a separate PR.

[hernandezc1]

This PR is extremely insightful as to how I should write code moving forward. The changes in main.py make the file readable--this is something I really appreciate.

My next task will be to review and keep an eye on PR #19 to understand how things are working under the hood.

[troyraen]

This is working. Going to merge and continue iterating.