fix: LSP initialization options

[aldur]

Description

A client can send partial initialization options, e.g.:

require('clarinet') -- Adds clarinet LSP
lspconfig.clarinet.setup(extend_config({
    cmd = {'/run/current-system/sw/bin/bash', '/tmp/wrapper.sh'},
    init_options = {completion = true}
}))

When that happens, the deserialization from the following code would fail, because all other required fields of InitializationOptions would be missing.

clarinet/components/clarity-lsp/src/common/backend.rs

Lines 372 to 376 in 90cb015

	LspRequest::Initialize(params) => {
	let initialization_options = params
	.initialization_options
	.and_then(|o| serde_json::from_str(o.as_str()?).ok())
	.unwrap_or(InitializationOptions::default());

This PR fixes that. In addition, it removes the unnecessary (I think) cast to string as we are already dealing with a serde_json::Value instance.

Breaking change?

No.

Example

See above.

---

Checklist

• Tests added in this PR (if applicable). Note: I have tested it manually through nvim LSP. It would be good if someone using VSCode could test it as well.

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
components/clarity-lsp/src/common/backend.rs	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[hugocaillard]

Tested in vscode and in zed as ac custom lsp.
It does make things better, thanks!