Problem:
If an LSP client sends a request with "params":null instead
of omitting the params field or smth like "params":{},
decoding error appears.
Solution:
Replace `null` value for "params" to `{}`
Problem: There was a misunderstanding when implementing this: batch
processing should not return responses individually, but rather return a
list with batch responses. This will require some further logic to group
such responses in order to process them in sequence.
Solution: We return those methods to being unhandled.
Problem: Linol can only send notifications from the server to the
client, but not requests.
Solution: The solution was inspired by Haskell's `lsp` package. We first
maintain a `server_request_handler_pair` data structure which represents
some server request and its associated response handler. Now
`notify_back` may take these fields and use it to actually handle a
request and its response. Changes to `notify_back` are propagated
throughout `server.ml`.
On `jsonrpc2.ml`, we refactor the notification and request handlers so
that we may handle the response and batch response handlers and batch
call as a courtesy. For a response, we keep a hash table that tracks an
ID to the `server_request_handler_pair` in other to be able to call the
handler that was associated with the response. After we get such
response (indexed by the server request's ID), we remove it from the
hash table to prevent a memory leak.
Since the server needs to keep track of the server request IDs, I added
a mutable `id_counter` in order to generate a fresh LSP ID (using
`fresh_lsp_id`) for every outgoing request.
For debugging, if we error while decoding a JSON, I now print the
exception too.
