CI: Reduce amount of release builds

[lsegal]

What happened?

Problem Statement

The build.yml workflow is configured to be a little to permissive in that it builds in too many scenarios:

1. Pushes to main
2. PR builds

While this is technically okay, these specific builds are release builds which are not very useful and take a lot of resources. They will build on all code change PRs in addition to regular CI tests.

In addition to this excessive building of PRs, we also have double builds on the PR -> release flow. Specifically:

1. In order to release, we create a PR which triggers a release build. This is a good thing, because it acts as a solid way to "stage" a build, or in this case, test that the release build works before performing it.
2. The problem comes into play when we merge to main, which triggers ANOTHER build. Because of the way we wire up deploy (and limitations on how git commit SHAs are wired up to the built assets), we are forced to use the merge to main as the release candidate, and therefore we must rebuild and throw the original PR build away. This means we have 2 expensive builds for one release.

Proposal

There are 2 things that can improve the workflow, the first being easy, the second a little bit harder (and potentially involved):

1. Only build "Release" PRs. This requires detecting the PR type via username/title which is done in the main merge step. Implemented in ci: only run release build on Release PRs #2238
2. Allow fast forward merges for release PRs so that the same artifacts can be used from the release PR (because it can be built off the same SHA); when pushing to main, pull artifacts from the workflow ID or upload the artifacts to a known location in S3 so they can be promoted upon merge. It could also be possible to run a specific job when the PR is merged

Alternate Proposal

The second option would be to do away with the "Release PR" altogether and trigger the workflow from the Release event. This would mean triggering a release by creating a Draft Release for a given tag and using a workflow tied to on: release events. This would trigger a build and attach assets to the release instead of artifacts of a build. Once the release is changed from "draft" to published, you can trigger a separate event to upload to S3 / promote.

However this approach requires significant changes to the flow and I don't recommend this approach unless absolutely needed.

What did you expect to happen?

Only perform release builds when releasing

Can you reproduce the problem?

Yes, consistently

CLI Version

N/A

Relevant log output