Refactor the JSON-RPC connection

[sylane]

Changed

• The name of the grisp_connect configuration key to control the timout of
  individual JSON-RPC requests changed from ws_requests_timeout ot
  ws_request_timeout.
• Le default log filter changed to trying to filter out only some messages to
  filtering out all progress messages, as it wasn't working reliably.
• The connection is not a persistent process anymore, it is now a transiant
  process handling a connection and dying when the connection is closed.
• Internally, the JSON-RPC is parsed into a list of atom or binaries to pave the
  road for namespaces. foo.bar.Buz is parsed into [foo, bar, <<"Buz">>] (if foo
  and bar are already existing atoms, but 'Buz' is not).

Fixed

• The client is now waiting 1 second before trying to reconnect when it gets
  disconnected fomr the server.

[sylane]

@maehjam It is less mixed up than it was, but I get that it may still be under documented. grisp_connect_jsonrpc is only doing JSON-RPC encoding/decoding, grisp_connect_connection encapsulate a JSON-RPC connection, and grisp_connect_client encapsulate the girps_connect client protocol.

[peerst]

This PR is stuck for a while now. Adding 1860 Lines and removing 430 is clearly beyond the size of reviewability (max 500 lines). How do we want to proceed with this? @sylane can you split it up in several PRs?

Also from what I can see so far: it looks in parts more like a rewrite than a refactoring. I'm not sure if that is due to too many refactoring steps stacked on top of each other so it only looks like a rewrite?

Rewriting or large refactors have a tendency to sneak in new bugs, so therefore require substantial improvement of testing at the same time: is that the case here?

How is the relationship between this code and DAB? Will this eventually end up in DAB? Parts of it? I don't want to have to maintain two forks of the same thing if that is the actual case.

[sylane]

@peerst This is already only some part of a bigger changeset that I split so it was simpler to review... Some changes already got merged in, but there is still more changes pending. The changes here are to go toward having a self-contained independent json-rpc client instead of having json-rpc logic spread everywhere in grisp-connect. So the connection is indeed a rewrite, but all the rest are changes to mostly remove things that are now abstracted by the new connection. I don't think I could easily split the changes further. For the testing, I wrote more tests, and I made the code more test-friendly, as the json-rpc connection can be tested completely independently. If we want more tests for it, I could write more, this shouldn't be complicated.

[ziopio]

Note that If this should ship in the default dettings for a grisp_connect based project we need to open a PR for rebar3_grisp/ grisp_tools to update the configuration for new generated user projects;
(rebar3 grisp configure)

[sylane]

I am not 100% sure that it make things better. It looked better for me, and this is the common solution I found about our problem with logging certificate, but others should test it too.

[maehjam]

I reviewed the first 8 files and found that the JSON-RPC API must be broken, since errors are not handled. I was wondering whether the tests wouldn't catch that. Please extend grisp_connect_api_SUITE to better cover the API. It only tests two methods.

I stop my review here till the tests pass.

There are already some change requests in the inline comments.

One other thing I noticed is that rebar.lock is missing. With the new jarl library as a dependency it should be updated.

[maehjam]

🚀