Sending read receipts

[exquo]

Originally posted by @exquo in #209 (comment)

This would be great! This feature has long been needed. Now that signal-cli has the dbus support for it (had it for while by now, actually) this really needs to be implemented in scli.

The biggest challenge is, as you say, detecting the user's "focus" (similar to #109), so that we only send read receipts for the likely-to-have-actually-been-seen messages. I think Signal-desktop has a leg-up with this: Electron probably makes available such information as whether its window is currently in focus, etc.

For the purposes of sending read receipts in scli though, I think we can just send them after any keyboard activity from the user, while the newly received messages are in view. Does that sound reasonable?
This will require writing some code for urwid's keyevents. I should be able to help with that, or point to the relevant documentation.

Another relevant issue (but a less important one) is that scli currently focuses the view on every newly received message. When there are many messages received in a chat, this results in some of the earlier ones scrolling out of the top of the view (since the latest message will always be made visible). So the last received message might be seen by the user before the first (unread) message. And so the RR will be sent for all the new messages in chat, even when the first one hasn't been seen yet.
The official clients handle this properly, by not allowing any of the unread messages to scroll out of view.
Fixing this would again require dealing with urwid's specifics (how items are focused in the corresponding ListBox object). This might be tricky, and probably not strictly necessary for implementing a good-enough read-receipt functionality.

Finally, some general notes on the sending-read-receipts functionality:

• This should be optional, so that users can opt out (scli's current behavior). Other choices can also be made available (if we think of them :), like under what conditions and how to send RRs.
• We'll need to check the produced implementation for not sending too many / redundant / repeated RRs. There are probably many ways to make this mistake, and initial attempts are likely make it.