Dependency triaging RLS and async/await

[workingjubilee]

While rust-analyzer is the preferred LSP solution, rust-analyzer still cannot fully replace RLS and RLS is still a tested submodule of rustc, and will likely be used for some time by the community. Accordingly, RLS could use a little tender love and care to its dependency tree, as rust-analyzer has gotten most of the action here.

A main source of "dependency decay"... dependence on old code that isn't getting much security/compat/enhancement maintenance... is the usage of mostly pre-async/await code in RLS and its dependencies. This currently keeps RLS stuck on an older version of futures and tokio. There are three major, obvious options:

1. Wait for Switch to std::future::Future paritytech/jsonrpc#485 to resolve
   Pros: Lazy!
   Cons: Parity began work on jsonrpsee to replace it, so it may never be moved fully over to tokio 0.2
2. Move jsonrpc -> https://github.com/paritytech/jsonrpsee as it becomes available
   Pros: Newer, maintained dep, eventually no loss of features?
   Cons: New, untested, possibly feature-incomplete for RLS' use-case.
3. Write some blocking JSON IPC as suggested here Remove duplicate dependencies for rustc itself rust#75704 (comment)
   Pros: Less dependence on complicated/newer features. Simplifies dependency tree greatly.
   Cons: Forfeiting async benefits, more effort, taking on maintenance burden directly

[cuviper]

The current dependency chain is also an issue for aarch64 windows: #1693.

[Xanewok]

I'll look into this this week; @workingjubilee thank you for the detailed write-up!

[Xanewok]

Update: paritytech/jsonrpc#485 is now fixed via paritytech/jsonrpc#603, so I believe this should be the way forward here, once jsonrpc is released including that PR.