refactor(codecatalyst): migrate client to sdkv3

[Hweinstock]

Problem

codecatalyst is still running on v2. Migrate to v3.

Solution

• refactor call wrapper to work with commands, rather than requests.
• Support passing token into V3 clients.
• Remove retry logic in tests, since V3 client builder adds this by default.
• correctClockskew is enabled by default so it can be dropped: https://github.com/aws/aws-sdk-js-v3/blob/eae65cded5e703306346bdbd1b5de9d23050054a/UPGRADING.md
• In SDKv3, all properties in the response are optional. However, in SDKv2 these were required. Therefore, we build a type where these properties are required to avoid undefined checks in many places. This involves wrapping some type guards due the problem discussed here, where type guards can't propagate up function scope.
• In SDKv3, errors are shaped differently (see: Error objects are different in v2 and v3 aws-sdk-js-v3#759). We rely on the shape to detect AccessDeniedException in CC, so this logic has to change.
• The token provider used here: https://github.com/aws/aws-toolkit-vscode/blob/master/packages/core/src/auth/sso/sdkV2Compat.ts#L33, does not work with V3, so we need to create one that does. This also means we can delete the old one, since this is the only place it is used.

Verification

• CodeCatalyst has some E2E tests. In addition to ensuring these pass, the following flows were manually tested:
  • connect to existing dev project and edit files, add files, and remove files.
  • clone an existing CC repo into a local folder.
  • create new dev environment and open it, make some edits, close it.
  • Try all the open commands that deep link to console.
  • List environments, repositories, and projects via QuickPicks.
  • Install extension on remote and verify CodeCatalyst panel is there and works.
  • Able to list projects, repos, and envs in CodeCatalyst env, but not able to connect (which is intended).
  • left the window open for 10 minutes then saw a warning.
  • Stop dev environment from within environment.

Future Work

• Look into adding the performance logging in the original call function to the default middleware stack for v3 clients.
• Add automatic mapping from name (or other) fields on service errors to make up for missing code property on errors in v3.

---

• 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.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.

[Hweinstock]

/runIntegrationTests

[justinmk3]

This code produced some nice, readable logs. Does the new client wrapper have that?

Is it feasible for the v3 client wrapper to have a call() function with similar features as this CC call() function? Maybe as a followup PR

[Hweinstock]

We have it logging this without the performance and headers information here:

aws-toolkit-vscode/packages/core/src/shared/awsClientBuilderV3.ts

Lines 202 to 207 in 4c190f4

	function logAndThrow(e: any, serviceId: string, errorMessageAppend: string): never {
	if (e instanceof Error) {
	recordErrorTelemetry(e, serviceId)
	getLogger().error('API Response %s: %O', errorMessageAppend, e)
	}
	throw e

. However, this isn't as detailed and could definitely be improved. I'll track it as a follow-up.