Cycle through hover results from multiple LSPs

[kyfanc]

replaces #9744 with improved UX.

inspired by #9974

This PR refactor LSP hover feature with the event system, with support of cycling through hover results from multiple LSPs.

keybinding:

• Shift+Left for previous hover
• Shift+Right for next hover

[kyfanc]

Also, seems there are some concurrency issues in the integration test.
It failed after ~6h in the previous action.

And i tried to run cargo integration-test locally in my mac, for both this PR & tag 24.03, both failed unstably.
like 2x out of 82 tests failed. but if I run them individually like cargo integration-test test::movement, the failed tests ran successfully.

Any idea?

[pascalkuthe]

I have very similar concerns/review as in #9974:

• you don't need to introduce a handler since this is not really async, the current hover code works fine. Eagerly requesting however from all lsps and then cycling trough them is much much simpler and more efficient. Specifically I refactoring the signature help with the event system because that is something that pops up automatically and hence needs timeouts/denounces. However is only requested by pressing <space>k so all that complex code is not needed
• keymap should be a-p and a-n to avoid conflicts yet stay consistent with feat: add symbol kind info in picker #9774

[kyfanc]

Thank for the review and comments.

The new push removed the unnecessary handler codes, and updated the keymap as suggested.

[cotneit]

This seems to be working great! Merge with master was pretty straightforward, just a few suggestions:

• I think it would be better to not display LS name if only one LS returned a result
• Bottom padding seems excessive, I think 1 line instead of 2 would be a better fit

For visual reference:
master

this PR

[kyfanc]

Thanks for the suggestions.
I have rebased onto master with some conflict resolved, and improved the UI as suggested.
This is how it looks like now.

Single result

Multiple results

[paulvandermeijs]

Great work!

I've been exploring the use of a language server to show git blame information on hover, which was pretty much useless without this. Only issue I noticed during development of the language server is that when the language server is slow or times out it will block messages from other language servers.

[kyfanc]

Thanks for your comment! The Git LSP sounds like interesting idea.

Regarding the blocking behaviour, it might be a bit complicated to manage UI interaction with the async responses from each LSPs. I am thinking about if it should display hovers preserving the order of LSPs in config, or by the response sequence from LSPs. It might better to be a separate PR as improvement.

I have rebased onto master with some conflict resolved.