Draft: feat: add remote security scanning

Description

This MR adds a feature that will allow users to scan their code for security vulnerabilities using a new feature in gitlab-lsp.

The following settings have been added:

• gitlab.featureFlags.remoteSecurityScans - passed to the language server to enable/disable responding to textDocument/didSave notifications
• gitlab.scannerServiceUrl - passed to the language server as the endpoint used (when the feature is enabled) to initiate a scan on save

The command gl.runSecurityScan has also been added, primarily for testing. It sends a textDocument/didSave notification for the current document, initiating a scan on demand.

Related Issues

• Add SAST scan feature to gitlab-lsp (gitlab#464097) • Jason Leasure • 17.2
• SAST Scanning in VS Code (gitlab#468473) • Erran Carey • Next 4-6 releases

For context

• the engineering epic: Static Analysis: real-time IDE SAST (&13753)
• the product epic: Scan for SAST findings as developers work in ID... (&10283)

How has this been tested?

The only testing has been ad-hoc using the collaborating branch in gitlab-lsp branch and a local instance of the scanning service.

1. checkout

   git clone -b add-lsp git@gitlab.com:gitlab-org/secure/sast-ide-integration.git
   cd sast-ide-integration
   ./scripts/setup.sh
   ./scripts/start-scanner-service.sh

2. Install or debug ./gitlab-vscode-extension.
3. Open a test project with the following settings

   "gitlab.featureFlags.remoteSecurityScans": true,

4. add a vulnerable file to the test project, e.g. a test file from the sast-rules projects like this one
5. save the file to kick off a scan.

To debug the language server, also add the following settings to the test project:

"gitlab.debug": true,
"gitlab.ls.debug": true,

and start watch

./scripts/start-lsp-watch.sh

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes