WIP Java CodeAction stub and resolve

[datho7561]

This is a POC for #171 (CodeAction resolve)

There are a few design decisions that make resolve implementation difficult:

• The main motivation for code action resolve is to avoid contacting the Java language server component every time diagnostics are triggered. Currently, all Java file code actions are calculated in the Java language server component
• We can extend the code actions provided in Java files via "org.eclipse.lsp4mp.jdt.core.javaFeatureParticipants", for instance in quarkus-ls. This means we don't know what CodeActions are included until runtime, so we can't just hardcode the CodeActions into the microprofile language server

Taking these into account, here is what I came up with (if there is a better way to get around this issue, please let me know):

1. Make a CodeAction "stub" that contains a template to create the title of the code action, which error codes it's applicable for, but doesn't include specifics like the TextEdit or the full Diagnostic
2. When the language server recieves the first CodeAction request in a Java file, it contacts the Java language server component, and asks for all codeaction stubs. It caches the list of all codeaction stubs
3. After it has the list of all the stubs, the microprofile language server converts all relevant codeaction stubs and turns them into unresolved codeactions with information from the CodeAction request parameters. (These unresolve code actions also have CodeAction#data to help resolve the codeaction)
4. When the user applies a given unresolved CodeAction, the edits are resolved by contacting the java language server component
5. Any future codeaction requests can be completed without contacting the java language server component, since the microprofile language server has cached the stubs

I'm currently a bit stuck with writing the stubs and codeaction resolve logic, since some of the code action participants generate (as an example) one code action for each config properties file in the project, and I need to figure out those cases.

[angelozerr]

I wonder if we could remove this codeActionStub by adding in JavaCodeActionContext a method like isResolveSupport that MicroProfile LS could fill by using the CodeActionResolveSupportCapabilities. It will give the capability to have just a method getCodeActions and according to isResolveSupport the TextEdit should be computed or not at this step.

[datho7561]

Please let me know if I understood what you are suggesting correctly: we add a parameter isResolveSupport to "microprofile/java/codeAction". If isResolveSupport is false, we return the resolved CodeActions (like we are currently doing), and if isResolveSupport is true, then we return the unresolved CodeActions (everything is filled in except the TextEdit).

If we do it this way, then we still need to contact the JDT component every time CodeActions are requested in a Java file, which if I understand correctly, is what we are trying to avoid and is the motivation behind adding resolve support.

[datho7561]

See #299