Automate external API versioning

[kurtisassad]

Link to Issue

Closes: #8890
Closes: #9500

Description of Changes

• Adds script which bumps the version in external-api-config.json (used as OpenAPI spec version)
  • Compares production OAS with locally generated OAS
• On startup of DYNO=web.1 in production, dispatch the SDK publishing workflow in the hicommonwealth/api-client repo if the latest version of the @commonxyz/api-client package is not equal to the current OpenAPI spec version.
• Adds Versioning.yml` action which only triggers on PRs that target the production branch
  • The action bumps the openAPI spec and api-client/package.json versions if necessary
  • Pushes directly to the PR
• Deleted libs/api-client since all of that configuration is moved to https://github.com/hicommonwealth/api-client

Test Plan

Versioning (Versioning.yml)

• Should pass when the version is not bumped: https://github.com/hicommonwealth/commonwealth/actions/runs/11732204426/job/32683945805?pr=9860
• Should auto-bump minor versions: https://github.com/hicommonwealth/commonwealth/actions/runs/11733516683/job/32687919766?pr=9860
• Should auto bump patch versions: this is broken because the OpenAPI-diff package we are using has a bug which misclassifies patches as breaking changes https://bitbucket.org/atlassian/openapi-diff/issues/38/issue-with-changing-a-property-from.

Publish workflow
Hope it works it on the next deployment. If it fails due to the commonwealth side function, dispatch the workflow manually from the api-client repository and fix the dispatch function in a PR.
- I tested everything in the dispatchSDKPublishWorkflow function except the API call to dispatch the workflow

Deployment Plan

• Make the version bumping CI job required before merging into the production branch
• Set API_CLIENT_REPO_TOKEN -> use the Common Workflow Dispatcher GitHub app token (@timolegros)

[Rotorsoft]

We might be able to get this diff without having to run the server. The spec can be generated by utils in /trpc/middleware via scripts. Maybe we can maintain the current master spec as a code artifact, and generate the diff by generating and comparing to the branch we are trying to merge, then update versions and spec with new spec.

[kurtisassad]

I think updating the branch with what we are trying to merge will lead to inflating our version numbering because it will basically bump the version numbering each time we make a new PR that changes the external API. I think it would be better to compare with the server.

I also see no reason not to run the server end to end. Not only is it easier it also guarantees we are comparing the same spec.

Anyways maybe we can discuss during platform hours

[timolegros]

What's the hold-up on this PR - can we get it out of draft or close it?

[timolegros]

I think updating the branch with what we are trying to merge will lead to inflating our version numbering because it will basically bump the version numbering each time we make a new PR that changes the external API. I think it would be better to compare with the server.

I also see no reason not to run the server end to end. Not only is it easier it also guarantees we are comparing the same spec.

Anyways maybe we can discuss during platform hours

One thing to note is that without the GENERATE_PRODUCTION_SDK=true environment variable, the generated SDK will have an API URL that defaults to local rather than production. So, in order to properly compare specs with production you need to start the localhost server with GENERATE_PRODUCTION_SDK=true.