Added more methods to work with matrix endpoints

[inaniyants]

Current PR description

As we use matrix protocol in a company I'm working right now, we have created https://github.com/Voronchuk/ex_matrix_api library to interact with matrix endpoints. Not so long ago, we have made a decision to unite our efforts with yours and to contribute to this repo instead.

In this PR I have implemented new methods to work with matrix endpoints, additional message types and formatting. Code coverage has been increased, right now it is 100%.

I have also added method to Client, which allows to run already constructed Request via client. For many reasons there could be necessity to build Request separately from its execution. Before this PR, request could be constructed with MatrixSDK.Client.Request and it could be executed with MatrixSDK.HTTPClient (or any other client). But this requires too much boilerplate (like to read which http_client to use from configuration), so instead I suggest to have ability to run Request directly with MatrixSDK.Client, which already knows how to read configuration and how to build default http client.

Other thoughts

Also, after diving into how this library is working and is being developed, I have a suggestion:
Right now library has not clear boundaries between MatrixSDK.Client and MatrixSDK.Client.Request modules, which causes too much duplication of code, docs and tests, which are hardening development, since it consumes a lot of time. As for me, main value of this lib lies in MatrixSDK.Client.Request module (it's role is to build a Request with help of good specs and docs). There is no need to duplicate same methods into Client, since its role is only to take a request and execute it via http protocol. For most of cases code will look like:

Request.logout("http://base_url", token)
|> Client.do_request()

Thats why I suggest to clear MatrixSDK.Client from any methods, that are not related to request execution. This would greatly simplify development for contributors, but won't affect developers, who are using library.

There also could be situations, when request should not be executed at all. For example: In most of cases download, thumbnail methods are needed to generate some urls, but not to do actual download. But current convention requires developer to place this methods into Client, which requires also to handle download and to cover it with test (which I haven't done). For url generation we could implement some helper method:

  @spec thumbnail_url(String.t(), integer(), integer()) :: String.t()
  def thumbnail_url("mxc://" <> path, width, height) do
    media_id = String.split(path, "/") |> List.last()

    %Request{base_url: base_url, path: path, query_params: query_params} =
      Request.thumbnail(base_url!(), server_name!(), media_id, width, height)

    Tesla.build_url(base_url <> path, query_params)
  end

But right now there is no context module to place such methods (it could be MatrixSDK.Client, but currently its concern is quite blurred).
It's hard to write and discuss all this in PR , so I suggest to do it via github issues or in your matrix room, etc.

[niklaslong]

Hi @inaniyants, first of all thank you for opening this PR (and issues), it's highly appreciated and I'm happy you've agreed to consolidate our efforts!

As this PR is quite large, I will need a little time to work through everything but after a cursory glance, this looks good.
On a more general note, thank you for the great descriptions and clarity in the points raised, this is really helpful.

I've opened #81 to move the discussion related to the Client module duplication out of this PR.

[niklaslong]

This is looking good!
Thank you for including documentation and full test coverage, it's highly appreciated. I left a few comments, mostly notes requiring no change as well as a few suggestions.

[niklaslong]

👍

[inaniyants]

In next PR's I'm going to add coveralls to project and set minimal code coverage for successful build. Code coverage percent will be displayed as a badge here also.

What minimal code coverage percent I should set ?

[niklaslong]

How about 90% for now? In general I'm not convinced code coverage should be a CI failing metric as I'd rather focus on tested functionality, but I think this number will leave us with some wiggle room and a decent measurement of the health of the tests.

[niklaslong]

We should either remove this in future for consistency or document it.

[niklaslong]

See comment related to this in room_event.ex.