GH-508: Support Call Hierarchy

[testforstephen]

close #508

I have two PRs to update lsp4j to adopt the new call hierarchy protocol.

• Update diagnostics tag for lsp4j eclipse-lsp4j/lsp4j#386 (the language client has adopted the new diagnostics tag support, so need update it to lsp4j too, otherwise, it's breaking jsonrpc.)
• Update call hierarchy for lsp4j eclipse-lsp4j/lsp4j#387

please use redhat-developer/vscode-java#1194 PR to integrate test this feature.

Thank @kittaakos for contributing the base PR #925, the new PR is based on that, and add changes to adopt the latest LSP for call hierarchy.

[fbricon]

Recursive calls are not handled properly, recursion should be limited. Compare vscode:

to Eclipse:

[testforstephen]

About fixing the recursive call problem, the server has to add some cache to record the visited history and use that to detect a ring. The jdt.ls just needs cache the method wrapper, and then call methodWrapper.isRecursive() method to check if it's ring. So for the cache mechanism, we must need some signal to clean up it too.

This works well for the normal "Show Call Hierarchy" view. Because it will send a new prepareCallHierarchy request whenever you hovers at a new position, click the buttons of refresh or switching the direction in the top right corner. So the server is able to leverage the prepareCallHierarchy request to clean up the cache.

But in "Peek Call Hierarchy" view, only hovers at a new position, VS Code will send a prepareCallHierarchy request. Clicking direction button at the top right corner will not send prepare request. So the cache has no chance to be clean up, and it may cause problems after you switch several times. See the issue microsoft/vscode#87176. Given the issue, i justdisable the recursion check by default, it's easy to add it back.

IMO, The resolving of the next level is driven by users, e.g by expanding tree nodes, the recursion may be not a big problem. In current stage, the correctness is more important than this enhancement. However, i will keep discussing with VS Code about the right solution to fix the recursion.

@fbricon How do you think?

[fbricon]

IMO, The resolving of the next level is driven by users, e.g by expanding tree nodes, the recursion may be not a big problem. In current stage, the correctness is more important than this enhancement. However, i will keep discussing with VS Code about the right solution to fix the recursion.

@fbricon How do you think?

Yeah we can probably live without recursion guard for now, and maybe try to figure out how to do it properly next