Refactored lsp--create-filter-function for lower latency and higher efficiency

[eval-exec]

• I added a new entry to CHANGELOG.md

• I updated documentation if applicable (docs folder)

This PR rewrites lsp--create-filter-function to use a buffer-based approach for processing incoming LSP messages. The new implementation accumulates raw input in a dedicated buffer, parses headers to determine message boundaries, and only decodes and processes complete messages. This design:

• Reduces latency: Calls lsp--parser-on-message immediately for each complete message instead of batching, improving responsiveness.
• Improves efficiency: Avoids unnecessary string concatenations and memory copies by operating directly on buffers.
• Enhances robustness: Properly handles incomplete header/body splits across multiple input chunks.

The new logic closely follows the LSP protocol framing, ensuring correctness and better performance, especially with large or fragmented messages.

No changes to external API or user-facing behavior.
All message parsing and dispatching are now handled more efficiently and reliably.

[kiennq]

The CI is failing which indicates that there might be edge case where this change fails to work. Can you make the CI passes?

[eval-exec]

The CI is failing which indicates that there might be edge case where this change fails to work. Can you make the CI passes?

Thanks for pointing it out. I’ll take a look and fix it later.

[eval-exec]

@kiennq Hello, CI passed, request code review. Thank you.

[kiennq]

Do we need this? Can't we do that in the input-buffer, i.e., move the cursor to header end and just call lsp-json-read-buffer, we save one copy to body buffer

[kiennq]

Use buffer-substring-no-properties

[kiennq]

Can we have a benchmark to see if this is really faster than the old one?
The old one already using temp buffer at the final step as part of optimization, this change expands that more so that we don't keep the list of input chunks but concat them right away.

Another thing with lsp--parser-on-message is that we can dispatch it on a timer, so we don't have to wait for a handler to run to parse the next one. The previous approach is we parsing all available message first and dispatch them one by one. The new approach on the other hand will try to execute lsp--parser-on-message as soon as we have data, however that can led to a long waiting period, especially around something like waiting for completion result.