fix(cloudformation): use static release manifest instead of GitHub Re…

[Zee2413]

…leases API

Replace GitHubManifestAdapter (GitHub Releases API) with direct fetch of the static release-manifest.json. Add CFN-specific manifest parser that respects the 'latest' flag per environment.

• Delete githubManifestAdapter.ts and utils.ts (addWindows, dedupeAndGetLatestVersions)
• Add cfnManifest.ts with parseCfnManifest() that prefers latest-flagged version
• Use ManifestResolver with real manifest URL instead of custom GitHub API resolver
• Make ManifestResolver.parseManifest protected for CFN override
• Add cfnManifest.test.ts with 5 tests

Problem

• the latest flag was not being used
• GitHub releases API fallback was unnecessary

Solution

• use remote manifest
• remove unnecessary GitHub release API

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[amazon-inspector-ohio]

⏳ I'm reviewing this pull request for security vulnerabilities and code quality issues. I'll provide an update when I'm done

[github-actions]

• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[amazon-inspector-ohio]

✅ I finished the code review, and didn't find any security or code quality issues.

[Zee2413]

• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.

  * Note: beta or "experiment" features that have active users _should_ announce fixes in the changelog.
  * If this is not a feature or fix, use an appropriate type from the [title guidelines](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#pull-request-title). For example, telemetry-only changes should use the `telemetry` type.
  

This is behind the scenes operation not seen by user.

[satyakigh]

We probably still want the fallback in case of throttles

[Zee2413]

We probably still want the fallback in case of throttles

If the raw.githubusercontent.com is throttled the GitHub API would not be helpful since the rate limit there is much lower. The API limit is 60/hr unauthenticated, 5000/hr authenticated (doc) whereas the raw user content limit (while undocumented) is believed to be 5000/hr (github blog)

[satyakigh]

We probably still want the fallback in case of throttles

If the raw.githubusercontent.com is throttled the GitHub API would not be helpful since the rate limit there is much lower. The API limit is 60/hr unauthenticated, 5000/hr authenticated (doc) whereas the raw user content limit (while undocumented) is believed to be 5000/hr (github blog)

This would be the fallback right, 5000 users would try the raw.github endpoint and be successful, the 5001 user would get throttled and fallback to GithubApi which would succeed

[Zee2413]

We probably still want the fallback in case of throttles

If the raw.githubusercontent.com is throttled the GitHub API would not be helpful since the rate limit there is much lower. The API limit is 60/hr unauthenticated, 5000/hr authenticated (doc) whereas the raw user content limit (while undocumented) is believed to be 5000/hr (github blog)

This would be the fallback right, 5000 users would try the raw.github endpoint and be successful, the 5001 user would get throttled and fallback to GithubApi which would succeed

The limits are not user-based, they're IP-based. The manifest is fetched once on startup so if there is any IP that is breaching these limits of 5000 of static content, the limit of 60 on the API (unauthenticated) is bound to be breached as well.

Keeping the API as a fallback added complexity in the workflow without much benefit.