improve latency of goto definition

So I was finally able to get rust-analyzer working in vim (with ALE), and it appears that fixing #1474 did the trick. So thank you! Working in crates like regex, I can definitely notice the speed improvements. RLS can take quite some time to catch up to changes in the source code, but rust-analyzer is almost instant.

I did, however, find a place where RLS appears to be much better: the latency at which go-to definition works. Here's the case I'm fiddling with right now:

1. Clone the rust-lang/regex repo.
2. Open src/prog.rs, go to line 24 and put the cursor over InstPtr.
3. Save the file. This should cause rls/rust-analyzer to start processing.
4. Run :ALEGoToDefinition as quickly as one can after saving. (Presumably, this problem isn't specific to ALE, so I guess replace this step with whatever command lets you jump to a declaration in your environment.) This should move the cursor just a few lines up to where the InstPtr type is defined.

When I do this for RLS, (4) succeeds pretty much instantly, even though RLS is still pegging my CPU. Presumably, RLS builds whatever index structure it needs for goto definition first, and is then able to use it even though it's still doing other work. (This is a guess based on observed behavior. I'm not familiar with RLS internals.)

However, when I do this for rust-analyzer, it takes about 5-7 seconds for the goto definition to actually move my cursor to the declaration site. Ideally, this should be as fast as RLS.

The overall goal I'm requesting here, I think, is to minimize the latency at which goto definition works after opening a file. This is a fairly common workflow for me personally, especially in code projects that I'm unfamiliar with, which lets me jump around to definition sites as quickly as I want.

Note that an alternative sequence of steps from the above set is to simply run :ALEGoToDefinition twice. The first time causes the language server to start, and the second time actually allows the language server to respond to the request. Now, with RLS, it seems like I can run goto definition twice as quickly as I want, and it will always succeed on the second request. But with rust-analyzer, I have to wait a second or two after the first press, otherwise the second request seems to just get ignored. Once the second request is made (again, after waiting for rust-analyzer to do its initialization), it is reliably successful, but only after 5-7 seconds, as with above.

Now, ideally, I could open a file, issue goto definition and have that succeed almost immediately. However, needing to do it twice (or save the file first) is an acceptable work-around to me personally. The much more important thing here, IMO, is minimizing overall latency. Moreover, I also understand that needing to do these key presses twice might not be a problem with the server, but rather the client. So it's less clear whether it's actually a bug in rust-analyzer or not.

Hopefully this is enough info to go on. These bug reports feel like they are super hard to work through. :-) My hope is that the latency question isn't specific to my setup, and it can be reproduced in other environments.

Reproduce the latency using rust-lang/regex/src/prog.rs, placing the cursor over InstPtr and invoking :ALEGoToDefinition after saving or opening the file. Compare rust-analyzer's response timing and repeated-request behavior with RLS, then trace the goto-definition request and initialization path. Done means goto definition responds with substantially lower latency during startup and repeated requests work reliably.