The "workspace/didChangeConfiguration" handler ignores message params

Chưa có ai nhận issue này.

When a client sends a `workspace/didChangeConfiguration` notification to the server, the server discards the message parameters entirely.

The LSP specification defines the type of the `params` property for this notification as:

```
interface didChangeConfigurationParams {
/**
* The actual changed settings
*/
settings: LSPAny
}
```

`LSPAny` leaves the door open for a server to handle this data arbitrarily, so I suppose it isn't a bug *per se* to handle it by discarding the settings . Nevertheless, the comment creates an expectation that the client can send the altered settings in the `settings` property, and the server will use them to update its configuration.

As near as I can tell, this is how most LSP servers behave, and what most LSP clients are expecting. For instance, this is the behavior of both neovim's built-in LSP client and the [ALE](https://github.com/dense-analysis/ale) plugin for (neo)vim.

Currently, unless `--configPath` is specified (in which case the notification is ignored), the handler for this notification patches the server configuration from these sources, in this order:

1. The folder-scoped configuration(s), pulled from the client via a `workspace.configuration` request
2. The `.luarc.json(c)` file in each folder
3. The global / unscoped configuration (`scope.fallback` in the source) pulled from the client via a `workspace.configuration` request

Notably, 1 and 3 only occur if the client advertised the `workspace.configuration` capability. If it did not, lua-language-server becomes completely unconfigurable via LSP alone. This is specifically a problem for ALE per [this issue](https://github.com/dense-analysis/ale/issues/4591).

I would propose that between steps 2 and 3, the server should patch `scope.fallback` with any settings provided in `params.settings`, using the same sections polled by the `workspace.configuration` message. In other words, identical to what is returned from `loadClientConfig()` in the config loader. Ex:

```jsonc
{
"method": "workspace/didChangeConfiguration",
"jsonrpc": "2.0",
"params": {
"settings": {
"Lua": {
"diagnostics": {
"enable": true,
"globals": ["vim"]
}
// etc.
},
"files.associations" = { /* ... */ },
"editor.semanticHighlighting.enabled" = true
}
}
}
```

This is consistent with how neovim and ALE -- and probably others -- already try to use the notification, and it won't affect anything for existing clients that don't send `params.settings` or that send then in some other unexpected format (their `params.settings` were ignored before and will continue to be ignored after).

I've made a fork with this proposed workflow [here](https://github.com/tmillican/lua-language-server), and I'd be happy to make a PR if this proposal sounds reasonable.

Tìm handler workspace/didChangeConfiguration và điểm vào của trình nạp cấu hình có tên loadClientConfig(), sau đó theo dõi cách scope.fallback được điền. Hoàn tất khi params.settings được áp dụng giữa các bước cấu hình theo phạm vi thư mục và cấu hình toàn cục, đồng thời vẫn giữ nguyên hành vi hiện có đối với settings bị thiếu hoặc không mong đợi và --configPath.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.