gopls/vulncheck: use result from gopls.vulncheck, rather than gopls.fetch_vulncheck_result

[findleyr]

In https://go.dev/cl/621055, I added support async request handling to gopls, using it to make long running command handlers run asynchronous to other LSP requests. This means that we no longer need our hacky gopls.fetch_vulncheck_result command to collect vulncheck results: the client can simply await the command result.

I didn't remove the gopls.fetch_vulncheck_result command. However, there IS an observable change in behavior for vulncheck integration in gopls: previously the gopls.run_vulncheck command would return quickly. Now it does not.

Therefore, we need to:

1. Check that this blocking of the workspace/executeCommand request doesn't cause problems for VS Code.
2. Eventually stop using gopls.fetch_vulncheck_result in VS Code.

[findleyr]

Decisions, from our meeting:

1. We'll revert gopls.run_vulncheck to its old behavior, since the new behavior breaks special handling to stream vulncheck results to a terminal.
2. We'll add a new gopls.vulncheck command that implements the new behavior. So the old behavior uses two commands (gopls.run_vulncheck and gopls.fetch_vulncheck_result), and the new behavior has just one (gopls.vulncheck).
3. We'll generalize the special handling that displays vulncheck results in a terminal output. Specifically, we'll document special metadata that gopls may embed in a header of the workDoneProgressBegin message.

In pseudocode:

workDoneProgressBegin{
  title: "⚡ govulncheck -C path/to/dir",
  message: "style: log\n\nStarting govulncheck...",
}

In this case, the header has a single piece of metadata: style: log, which signals to clients that the preferred output style for this progress notification is a log (=append) style. Of course, most clients will not have any special handling, but the default UX will be somewhat reasonable: the progress notification will show the most recent log message. Previously, we had discussed style: terminal, but @adonovan points out that this may make it unclear whether the output should support ANSI escape codes.

CC @hyangah @h9jiang @adonovan

[adonovan]

FWIW this is the upstream issue for the LSP protocol change that would make this unnecessary:

• support for executeCommand to produce additional output streams through the progress notification mechanism microsoft/language-server-protocol#2014

(Which will happen first: this proposal getting approved, or the sun exhausting its nonmetallic fuel? Only time will tell!)