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.

[maehjam]

Can you explain to me the different purposes of the modules grisp_connect_connection, grisp_connect_client and grisp_connect_jsonrpc. First impression is that it's all mixed up. This needs better documentation.

[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.

[maehjam]

1. The logger changes and architecture changes of the websocket connection shouldn't be in the same PR. Both are changes in parts that are hard to test. They each need very careful testing and probably manual testing in addition to the automatic testing.
2. Is this working with the current grisp_manager implementation or do we need to adjust grisp_manager as well?

[maehjam]

You could have just fixed last_seq/0 to do that. Now we do more or less the same twice.

[sylane]

True, it ended up like this because I tried a lot of different ways to fix the issue, and the last working one could have been done in last_seq/0. I could change that.

[maehjam]

Why remove the logs?

[sylane]

Because now there is not always a permanent connection process, it may not be there and instead of trying to do some error handling and showing the state only when the connections there, given it is only debug information I just removed the line.

[maehjam]

You have connect and disconnect in every test case. I would do that in init_per_testcase and end_per_testcase.

[maehjam]

I feel with the timeouts and the distinction between connected and disconnected in handle_call this would be much better readable as a gen_statem. The module name is a bit strange, I liked grisp_connect_ws better.

[sylane]

It does way more than the old grisp_connect_ws. This remove complexity not related to the API from the client and API and could be reused easily. What would be the states if it was a statem ?

[sylane]

1. The logger changes and architecture changes of the websocket connection shouldn't be in the same PR. Both are changes in parts that are hard to test. They each need very careful testing and probably manual testing in addition to the automatic testing.
2. Is this working with the current grisp_manager implementation or do we need to adjust grisp_manager as well?

I only change the logging int he new code, I didn't touch the logging in the old code.
The change in the logging is due to the connection not being a persistent process anymore, and this is part of the connection architecture change.

What do you mean by these change shouldn't go together ?