Improve typing notification alert

When a user sends a message, client executes a first HTTP request to inform server of the stop typing event(@PUT("rooms/{roomId}/typing/{userId}")), and then send the message.

Other clients see the typing notification disappear (threw /sync) and after a while, the message is received (threw another /sync).

Other clients cannot know if the typing notification disappears because of the remote user stops typing or cancel the typing, or because of the fact that a message has been sent.

This is not comfortable regarding UX.

It could be more synchronous so clients may update UI smoothly by making the typing notification disappears along with the new message appears.

Possible solutions:

• Add a timer when stop typing event is received to cancel its display when the message from this user arrives (no API change needed then)
• Change API @PUT("rooms/{roomId}/typing/{userId}") to add a boolean set to true if user stop typing due to message being sent, and false for other cases. Client could then wait for message to come.

Points to keep in mind:

• User can send message and right after start typing a new message. Client should not dismiss typing notification when the first message is displayed
• There is no strict ordering between events & typing notifs; they can be misordered, delayed, typing notifs can go missing entirely. for a robust solution you'd almost certainly have to tie an ID on the notif to an ID on the event which resulted from it.

Start with the typing endpoint @PUT("rooms/{roomId}/typing/{userId}") and trace how typing notifications and message events are synchronized. Review the two proposed approaches and the ordering, delay, and missing-notification constraints; the work is complete only after the protocol behavior and client-visible result are agreed.