feat: common CLI dir checks in connectivity checker [IDE-1557]

[rrama]

We have a customer who was having issue with the CLI download directories, this should help diagnose the problem. We can't have these directories be checked by just the LS (like I will do with delta scans having them be passed in the config to check), as it would be a chicken and egg problem. Although, giving it more thought while typing this, we could instruct customers to use a CLI binary in a temporary location for testing and then load the dirs from the IDE...

Additionally:

• Output the env vars: NODE_EXTRA_CA_CERTS, KRB5_CONFIG, and KRB5CCNAME.
• NODE_EXTRA_CA_CERTS is not mentioned in the docs, but is supported and even recommended by this tool itself.
• Kerberos ones are mentioned in the docs here.
• Fixed a bug where a failure to retrieve the orgs would be considered a formatter error, preventing output.
• Output the current user's username.

This is heavily vibe coded, so do fully scrutinise it.
The AI told me about the directory I labeled "Runtime Cache for Temporary Files", I haven't fully confirmed its actual use, but does indeed seem to be the cache dir for GAF.
If you would prefer this to be its own workflow and/or with a generic diagnostics workflow, then I can do that. I just didn't want to invest too much time into this before getting people's thoughts on it.

New output on MacOS

Current User Information

Username: ben

Potential Snyk Used Configuration and CLI Download Directories

Directory: /Users/ben/Library/Application Support/snyk/vscode-cli (Purpose: Default CLI Download Location for VS Code Extension)
✓ Exists
✓ Writable (permissions: 0755)
Found 1 potential Snyk CLI binary/binaries:
• snyk-macos-arm64 (permissions: 0744)

Directory: /Users/ben/.local/share/snyk/vscode-cli (Purpose: Alternative CLI Download Location for VS Code Extension)
⚠ Does not exist
Nearest existing parent: /Users/ben/.local/share
✓ Writable (permissions: 0755)

Directory: /Users/ben/.snyk (Purpose: Default CLI Download Location for Eclipse Plugin)
✓ Exists
✓ Writable (permissions: 0755)
Found 1 potential Snyk CLI binary/binaries:
• snyk-macos-arm64 (permissions: 0744)

Directory: /Users/ben/.local/share/snyk-ls (Purpose: Default CLI Download Location for Language Server)
⚠ Does not exist
Nearest existing parent: /Users/ben/.local/share
✓ Writable (permissions: 0755)

Directory: /Users/ben/Library/Application Support/snyk (Purpose: Language Server Config Storage)
✓ Exists
✓ Writable (permissions: 0755)

Directory: /Users/ben/Library/Caches/snyk/snyk-cli (Purpose: Runtime Cache for Temporary Files)
✓ Exists
✓ Writable (permissions: 0755)

New output on Windows

Current User Information

Username: BENDURRANS6F87\ben

Potential Snyk Used Configuration and CLI Download Directories

Directory: C:\Users\ben\AppData\Local\snyk\vscode-cli (Purpose: Default CLI Download Location for VS Code Extension)
✓ Exists
✓ Writable (permissions: 0777)
Found 1 potential Snyk CLI binary/binaries:
• snyk-win.exe (permissions: 0666)

Directory: C:\Users\ben\AppData\Local\Snyk (Purpose: Default CLI Download Location for Eclipse Plugin and Visual Studio Plugin)
✓ Exists
✓ Writable (permissions: 0777)
No Snyk CLI binaries found

Directory: C:\Users\ben\AppData\Local\snyk (Purpose: Language Server Config Storage)
✓ Exists
✓ Writable (permissions: 0777)

Directory: C:\Users\ben\AppData\Local\snyk\snyk-cli (Purpose: Runtime Cache for Temporary Files)
✓ Exists
✓ Writable (permissions: 0777)

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[bastiandoetsch]

I think this should be its own tool. It does not belong into the connectivity check. It actually should probably be implemented in LS, as this contains IDE logic.

[rrama]

@bastiandoetsch Happy to move it to its own tool.
But I would suggest it needs to be available in the CLI, as its close to being a chicken and egg problem. If it was in LS-only, it would require the customer to set a manual CLI path in the IDE to then have it diagnose why the default download location cannot be downloaded to (an issue a customer is possibly currently facing). So, it is possible to have it LS-only, but the user experience would be worse IMO. I can see the counter argument of this being a tool that will only be run very infrequently and only in a few odd cases as directed by support, so can be a bit more of a convoluted process. Thoughts?

[bastiandoetsch]

@bastiandoetsch Happy to move it to its own tool. But I would suggest it needs to be available in the CLI, as its close to being a chicken and egg problem. If it was in LS-only, it would require the customer to set a manual CLI path in the IDE to then have it diagnose why the default download location cannot be downloaded to (an issue a customer is possibly currently facing). So, it is possible to have it LS-only, but the user experience would be worse IMO. I can see the counter argument of this being a tool that will only be run very infrequently and only in a few odd cases as directed by support, so can be a bit more of a convoluted process. Thoughts?

I don't see why the user experience would be worse - if it lives in the LS repository, it would still be compiled into the CLI binary and could be used both from terminal and IDE. Or do I understand something wrong? Testing things from the IDE may be more valuable anyway, as environment shenanigans may not happen in the terminal, but within IDEs launched from the desktop directly, where launchd (or similar) don't inherit the shell environment.