feat: 260 refactor database update

[jcpitre]

Resolves #260
This PR replaces PR #1426 that was reverted in #1431

Refactored the db-update.yml workflows to have 2 completely separate path for running the update directly (or via a release) and running it if the catalog changes.

Now if called with a workflow_call (presumably from one the release workflows) we only update the schema via db-update (which maybe should be renamed db-update-schema, but I wanted to limit the number of changes).

If called from a repository_dispatch, i.e. from the catalog repo, we only update the contents of the DB using the populate script of the same version as what is installed in GCP (or said otherwise we checkout the same version as what is installed on GCP before running populate). This is done for DEV, QA and PROD at the same time.

From Copilot:

This pull request introduces significant improvements to the GitHub Actions workflows for the Mobility Database project. The main changes include modularizing and enhancing the database content update process, adding robust support for resolving API metadata, and improving Slack notification handling for workflow failures. These updates make the workflows more maintainable, reusable, and reliable across environments (dev, QA, prod).

Workflow modularization and enhancements:

• Introduced a new reusable workflow .github/workflows/db-update-content.yml to handle database content updates, secret management, and log artifact uploads, improving separation of concerns and maintainability.
• Added .github/actions/resolve-api-meta/action.yml, a composite action to robustly resolve the deployed API commit SHA and version from the API's metadata endpoint, handling token exchange and failures gracefully.
• Created .github/workflows/catalog-update.yml to orchestrate catalog-driven content updates for dev, QA, and prod environments, using the new resolve-api-meta action and db-update-content workflow, and triggering Slack notifications on failure.

Notification improvements:

• Enhanced .github/actions/notify-slack/action.yml to support a new "test" priority level and refactored the alert message logic for clarity and extensibility. [1] [2] [3]

Testing tips:

Some of the workflows can be triggered by hand. Each one has a DRY_RUN parameter.
Tested with this DRY_RUN:

• db-update-dev.yml

• db-update-qa.yml

• db-update-prod.yml

• Tested by manually running catalog-update.yml: https://github.com/MobilityData/mobility-feed-api/actions/runs/19084169644

  • Since it's not possible to run a new workflow that is not present in the main branch, I used duplicate-prod-db.yml to temporarily host the code of catalog-update.yml in the PR branch

• Also tested by launching a full scale QA release: https://github.com/MobilitData/mobility-feed-api/actions/runs/19103854755

• Did not test a prod release.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with ./scripts/api-tests.sh to make sure you didn't break anything
• Add or update any needed documentation to the repo
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)

[davidgamez]

LGTM