test(ec2): ensure that private key is not written to telemetry

[Hweinstock]

Problem

We want to enforce that the private key generated by the toolkit is not accidentally slipped into a telemetry metric.

Solution

Similar to assertTelemetry, we implement a assertNoTelemetryMatch test utility that scans all metrics to see if a specified keyword is included in its keys or values.

With this utility, it is relatively straightforward to assert that this private key doesn't appear in the telemetry when we generate it and perform other operations with it.

---

License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[justinmk3]

Windows failure . The c:\Users\RUNNER~1\ path looks suspicious but might be just cosmetic. Note from https://nodejs.org/api/fs.html#fschmodpath-mode-callback :

on Windows only the write permission can be changed, and the distinction among the permissions of group, owner, or others is not implemented.

So if write perms is not important here, as a workaround maybe we can skip that on Windows for now (in sshKeyPair.ts)

  1) Ec2ConnectClient
       sendSshKeysToInstance
         avoids writing the keys to any telemetry metrics:
     Error: ENOENT: no such file or directory, chmod 'c:\Users\RUNNER~1\AppData\Local\Temp\aws-toolkit-vscode\vsctkdc5cd3f6\keys'
      at async chmod (node:internal/fs/promises:1096:10)
      at async FileSystem.chmod (D:\a\aws-toolkit-vscode\aws-toolkit-vscode\packages\core\src\shared\fs\fs.ts:392:13)
      at async Function.generateSshKeyPair (D:\a\aws-toolkit-vscode\aws-toolkit-vscode\packages\core\src\awsService\ec2\sshKeyPair.ts:40:9)
      at async Function.getSshKeyPair (D:\a\aws-toolkit-vscode\aws-toolkit-vscode\packages\core\src\awsService\ec2\sshKeyPair.ts:31:9)
      at async Context.<anonymous> (D:\a\aws-toolkit-vscode\aws-toolkit-vscode\packages\core\src\test\awsService\ec2\model.test.ts:159:26)

[Hweinstock]

Based on https://help.ubuntu.com/community/SSH/OpenSSH/Keys it sounds like keys should already have these permissions set correctly. So this chmod is mostly a double-check since the agent will throw an error if the permissions are too open.

I changed the code to throw a more useful error, and only do chmod on non-windows.

[Hweinstock]

Seems like there is a more general problem of the key not existing on windows after write. Investigating now.