Reconsider `Diagnostic.actions` (`CodeAction` property) for quickfix

Ref https://github.com/microsoft/language-server-protocol/issues/581
Ref https://github.com/microsoft/language-server-protocol/issues/887

Problem

Hi, I am a maintainer of Scala language-related tooling, for example its incremental compiler Zinc etc.
We are currently in the process of implementing actionable diagnostics, which allows the Scala compiler and build tools to expose code edit suggestions via Diagnostic. Likely this will proceed using the Diagnostic.data.actions field.

As far as I can tell, most languages interested in using Diagnostic.data are interested in passing along CodeAction quick fixes. So far:

• clang (done as Diagnostic.codeActions)
• Scala (in progress)
• Erlang
• Rust
• XML

Am I wrong to assume that not having this standardized means that the LSP clients need to implement the embedded CodeAction support one by one for each language?

Possible Solution

I think this is a clear signal that we should standardize list of CodeAction as Diagnostic.actions. Maybe it could be paired with WorkspaceEditClientCapabilities to opt-into or out of having actions attached.

Notes

The primary reason "quick fix" did not happen previously seems to be based on the assumption that that computing the code suggestion would be expensive. Some code suggestions might be, but:

1. There are many other cheap code fixes, often already suggested via deprecation warning messages. See for example https://github.com/scala/scala/pull/10406.
2. There are also some class of warnings that only compiler can accurately emit because it has the precise knowledge that is often expensive for external linters to re-emulate. In Scala community, there are syntactic Scalafix and semantic Scalafix, and the latter can be very slow. An example of this is unused import statement. Another example is organizing import statements, because import in one line can affect the imports in latter lines.

Start by reading the referenced language-server-protocol issues 581 and 887, then compare the proposed Diagnostic.actions property with the existing Diagnostic.data.actions approach described here. Determine whether CodeAction quick fixes should be standardized and how WorkspaceEditClientCapabilities would opt in or out; done means reaching and documenting a protocol decision.