Confusing to handle code actions of kind "source" similarly as those of type "quickfix"

For this issue we can start from the same scenario as in my last issue: https://github.com/eclipse/lsp4e/issues/866.

There I focused on the case where there are >1 language servers configured, and, for a given diagnostic, we have a race condition on querying each LS for a code action.

However, I think it's worth taking a separate look at this scenario from a different angle.

In this environment, the code actions provided by the one LS (LSP4Jakarta) are all of code action kind = "quickfix". The code action provided by the other LS (LSP4MP) is of kind = "source".

In VS Code, the "source" kind code actions are not accessible via the "light bulb", but instead are accessed by right-clicking to bring up the context menu, and then choosing "Source Action" (and then you get the list of actions).

It seems like in Eclipse we might also treat this kind of code action differently. Instead of populating the "marker" (I believe that's the term) and treating it parallel to the other "quickfix"-kind of code actions, maybe this should be accessible only via the "Source" menu?

One thing that sets it apart from quickfix code actions is that I believe the user expectation for a quick fix is that, once you apply it, the choice then disappears. You don't typically have the option to apply a quick fix repeatedly. I think, though, that the "source" kind of code actions might be used in contexts where you do have the option to apply repeatedly (even if nothing happens the second time).

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction

Is it possible that a fix could involve something like taking the LSPCodeActionMarkerResolution code and adding a filter to only consider quickfix kind actions? Haven't tried making any edits myself with lsp4e; I wonder how long it'd take me to try coding that up.

Start with LSPCodeActionMarkerResolution and the code-action handling described in the issue, then compare the behavior with the LSP 3.17 textDocument/codeAction specification. Determine how quickfix and source actions are currently surfaced, and verify that the finished change distinguishes their access paths without breaking the existing multi-language-server scenario.