feat: Install the right DB version when updating the DB contents

[jcpitre]

Note: This PR was reverted in #1431 and a new PR was merged to replace it: #1436

Modified the DB update github actions to query the currently installed DB version and use this version for the update.
This was considered simpler that creating a GCP function.
Closes #260

AI summary

This pull request introduces significant improvements to the database update workflows for all environments (dev, QA, prod) by making the process more flexible, safer, and better aligned with the deployed API version. The main enhancements include support for dry runs, the ability to select between deploying the latest or currently deployed API version, and the introduction of a new composite GitHub Action to automatically resolve the deployed API commit and version. These changes help ensure that database schema and content updates are consistent with the actual API deployment, and provide safer manual and automated update options.

Key changes:

1. Workflow flexibility and safety improvements

• Added DRY_RUN and INSTALL_LATEST inputs to all update workflows (db-update.yml, db-update-dev.yml, db-update-qa.yml, db-update-prod.yml), allowing users to skip actual updates or choose which API version to install. [1] [2] [3] [4]
• All update jobs now respect the DRY_RUN flag, conditionally skipping schema/content updates and secret updates when enabled. [1] [2] [3] [4]

2. API version resolution and alignment

• Introduced a new composite GitHub Action (.github/actions/resolve-api-meta/action.yml) that queries the API metadata endpoint to resolve the currently deployed API commit SHA and version using a refresh token.
• Added a dedicated resolve-api-meta job to db-update.yml that runs before schema/content updates, ensuring that the correct code version (commit SHA or main) is checked out for database updates, depending on the INSTALL_LATEST flag.
• The workflows now pass the appropriate API base URL and refresh token secrets for each environment to support secure and accurate API version resolution. [1] [2] [3] [4] [5] [6] [7]

3. Improved job dependencies and code checkout

• Update jobs now use the resolved API commit SHA (or default to main) for code checkout, ensuring that database updates are always performed against the correct API version. [1] [2]

4. General workflow enhancements

• Improved conditional logic for when to install the latest API version versus the currently deployed one, based on the event type that triggered the workflow (manual, repository dispatch, or workflow call). [1] [2] [3]
• Added documentation and descriptions for all new inputs and outputs, making the workflows easier to understand and maintain. [1] [2]

These changes collectively make the database update process more robust, transparent, and aligned with the actual API deployment lifecycle.

Testing tips

Testing was done using the DRY_RUN option for dev, QA and prod. Using the INSTALL_LATEST option I could verify both using main or the currently installed version.

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]

Great work on fixing this! 🥇