cd: Create direct CDN deployment and NPM deprecation workflow

[adebayor123]

Description

This PR introduces two new workflows to help with the deprecation process for both CDN and NPM releases. For CDN:

• Previous method involved re-releasing the previous stable version to overwrite the 1.x versions. This had to rely on the existing CD workflow, which triggers smoke test and NPM release as well.
• Instead, this PR creates a workflow dedicated to just re-releasing with a previous stable version without the smoke test or the NPM release. This helps reduce the time to deprecate for CDN releases. Verified in GAMMA stage.
• To use this workflow, the contributor will create a release branch of a previously safe commit, trigger this workflow.

For NPM:

• Previously to deprecate, we relied on manual work. This PR creates a workflow that requires two inputs, 1) deprecating version and 2) deprecating reason. With these inputs, the workflow will automatically deprecate the NPM version.
• Tested with https://www.npmjs.com/package/aws-rum-web-experimental/v/1.9.0-alpha.0

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[limhjgrace]

question: In our rollback steps to deprecate CDN, the runbook indicates that we need to "Revert the affected major (M.x) and minor (M.m.x) auto-update versions to the previous good version by deleting the bad (most recent) version." Do we not have to still delete the bad (most recent) version? Or does deploying the previous stable version do this under the hood?

[limhjgrace]

question: In our rollback steps to deprecate CDN, the runbook indicates that we need to "Revert the affected major (M.x) and minor (M.m.x) auto-update versions to the previous good version by deleting the bad (most recent) version." Do we not have to still delete the bad (most recent) version? Or does deploying the previous stable version do this under the hood?

Synced offline that the intended behavior should be to only release previous stable version to update 1.x or 1.x.x, not remove the bad version. LGTM.

[qhanam]

Regarding the CDN workflow, is there any disadvantage to re-running the smoke tests? I feel like doing that validation after deployment can only be a good thing.

What do you think about merging these two scripts into a single "deprecate" workflow?

[adebayor123]

Regarding the CDN workflow, is there any disadvantage to re-running the smoke tests? I feel like doing that validation after deployment can only be a good thing.

Validation is good, but my thought was that since this previous good version already went through smoke test during its release, we don't necessarily need to run the smoke tests again. More than happy to include smoke tests.

What do you think about merging these two scripts into a single "deprecate" workflow?

I've thought about it, and I prefer to separate them - NPM deprecation workflow allows you to select a specific version and add a deprecation message regardless of what branch you're on, as NPM version deprecation does not depend on the branching system we have for version releases. On the other hand, if we wish to trigger release for previous good version for CDN, we need to go to the specific release branch.

If we combine the workflows and we wish to deprecate 1.13.6 - we need to go to branch 1.13.5 or 1.12.x and run CDN while adding 1.13.6 as the version we wish to deprecate. This felt a bit more confusing than to running the NPM workflow then going to a specific branch to re-run the release.

Another issue I saw was just separation of concern for the use cases - what if we just need to deprecate a certain NPM version from the past? In that case, we don't need to trigger a new CDN release, necessarily.