bugfix: Don't send and display typing updates from oneself.

[prah23]

First commit:

• Typing events from oneself are currently handled and
  displayed on the footer. This commit adds an extra check in the
  typing event handler's conditional to verify that the sender
  isn't the logged in user themselves before displaying the update.
  Tests added.

Second commit:

• Prior to this commit, typing updates were sent to all recipients of
  the current private message as specified in recipient_user_ids,
  which is an unnecesary expense for the server though minute.

• This commit uses another list, typing_recipients, that stores all the
  recipient user_ids except for the user's own, that can be used to send
  typing updates. This list is initiated as a part of WriteBox for
  persistence to send start and stop updates.

[neiljp]

@prah23 I can reproduce this issue - thanks for finding it and proposing a solution 👍

If I type in the webapp, then it does currently generate an event - shown in ZT on main - but doesn't show typing events in the webapp. So, this PR does fix this by blocking the final round-trip in such cases.

My concern is whether this solution is where the fix is ultimately important, or if it should be:

• client-side for us (we check if sending into a particular conversation and block it) - it's a very minor network optimization anyhow!
• server-side (the server blocks sender-id being one-person-sender PM narrows from triggering typing events)

Given the webapp doesn't show self-self typing notifications, I assume this is a minor bug in the server in a corner case, that should likely be fixed there, and we could skip sending such notifications in the first place instead of not acting on the events.

Even if the server doesn't change event handling and we adjust our sending, that would then leave the only case being "someone" typing in your account somewhere else triggering our event handling, which is then even more of a corner case. However, let's see what the server code looks like and if it's considered a bug there, for that case?

[prah23]

Further context for anyone reading, this was discussed further at
#zulip-terminal > Typing status bugfix #T1011 and #backend > Send typing status when in narrow with oneself.

[neiljp]

@prah23 Just checking in on this small edge-case PR from a while back - it's well-structured and works fine, just a few queries before we merge 👍

[neiljp]

This is nice simple extra variable which works fine. My only thoughts are:

• Maybe append _user_ids to indicate more clearly what's in it elsewhere
• Should it be reset everywhere that recipient_user_ids is? It doesn't currently appear to be? (I know they have different uses, but it seems useful to be consistent)
• If we're resetting/setting at similar times, should that be in a function, existing or otherwise? (maybe a refactor?)

[neiljp]

@prah23 See my comment in the stream - I've also rebased this to resolve the minor conflict. This seems like an easy merge if my proposed changes look good to you 👍

[prah23]

Thanks for resolving the conflict and extending the work @neiljp! The changes look good to me 👍. The method introduced here can be easily incorporated into #1057, and will help keep both types of user_ids in sync.

[neiljp]

@prah23 Thanks for getting back quickly so we can get this in - I merged as the commits prior to 733926d 🎉