Publish openAPI yaml in ci/cd

[aaazzam]

Closes #14970, by autogenerating an openapi.yml in src/prefect/_internal in the static_analysis workflow.

Eventually I'd like to make this a 'public' file, but starting in _internal while the only known use case is #15512, which will use this file in openapi-ts to autogenerate a fetching service layer for the UI.

Briefly considered moving it to pre-commit, but doesn't seem appropriate.

[aaazzam]

🤦 The GH Action is writing but not persisting the file.

[desertaxle]

I like the idea of doing this in CI so developers don't have to remember to generate this file before opening a PR! I don't think we have any GH workflows that commit files to a PR on the submitter's behalf, so we'll have to figure out how to do that. This example for the checkout action looks promising.

[desertaxle]

What do you think about creating a separate code/schema generation workflow? I see that it's currently in the static analysis workflow, but I'm not quite sure it fits there.

[cicdw]

@aaazzam I don't think building this in the static analysis CI job makes sense unless the goal is to test that it can be built successfully. If the goal is to publish this spec within the package, then I think the best way is probably:

• add it as a pre-commit hook similar to the mintlify openAPI schema generation (can we just copy/paste this into a new location?)
• expose a CLI to build this on the fly (similar to how the UI gets built)
• we may also need to consider running this schema-build within the release workflow to ensure it's up-to-date, but that might be unnecessary
• lastly, it'll need to get added to the package manifest

[aaazzam]

@cicdw I avoided putting it in pre-commit at first b/c import prefect can still be a little slow and putting that import tax on every commit felt heavy handed. After iterating on this PR though I agree that doing magic commits on your behalf on push is wayyy more heavy handed.

Will move this to pre-commit, and great call out on the package manifest.