Add autocomplete for initialization_options

[Nereuxofficial]

Closes #18287

Release Notes:

• Added autocomplete for lsp initialization_options

Description

This MR adds the following code-changes:

• initialization_options_schema to the LspAdapter to get JSON Schema's from the language server
• Adds a post-processing step to inject schema request paths into the settings schema in SettingsStore::json_schema
• Adds an implementation for fetching the schema for rust-analyzer which fetches it from the binary it is provided with

Open Questions(Would be nice to get some advice here)

• Binary Fetching:
  • I'm pretty sure the binary fetching is suboptimal. The main problem here was gettiung access to the delegate but i figured that out eventually in a way that i hope should be fine.
  • The toolchain and binary options can differ from what the user has configured potentially leading to mismatches in the autocomplete values returned(these are probably rarely changed though). I could not really find a way to fetch these in this context so the provided ones are for now just default values.
  • For the trait API it is just provided a binary, since i wanted to use the potentially cached binary from the CachedLspAdapter. Is that fine our should the arguments be passed to the LspAdapter such that it can potentially download the LSP?

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have @Nereuxofficial on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[Nereuxofficial]

@cla-bot check

[cla-bot[bot]]

The cla-bot has been summoned, and re-checked this pull request!

[probably-neb]

To answer your questions

How should the JSON schema be provided?

The schema should be provided as a serde_json::Value or JsonSchema object (just a wrapper around the serde_json::Value from the LSP Adapter as you have done already.

Based on the JSON Schema spec and the behavior of the VSCode JSON Language Server (the one Zed ships with), if it is just a file, the adapter can return { "ref": "file:///path/to/file" } and the JSON LSP will read it as needed (This isn't entirely true, remote editing is a thing but we can solve that when we get there), same goes for a URL where the schema is hosted.

How should the format be enforced? To provide nicer errors to plugin developers we should probably tell them if the format the plugin provides is wrong. Can we maybe use the JsonSchema type and test there if the format is correct?

I'm not quite sure what you're asking here, but I'm going to assume you mean how do we verify that the schemas the adapters give us are correct - Feel free to correct me if I'm misunderstanding.

In short, I don't think this is a problem worth solving. It is up to the extension author to provide the correct schema.