Disappearing messages and manual deletion, interfere with conversation-list sort order

[x] I have searched open and closed issues for duplicates
[x] I am submitting a bug report for existing functionality that ~~(probably)~~ does not work as intended(?)
[x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
[x] This ~~isn't(?) a feature request~~ or a discussion topic

Later edit: turns out I was wrong, the behavior described below is ByDesign, per comment by Greyson below. https://community.signalusers.org/t/improve-conversation-ordering-disappearing-messages/5235 is the feature-request thread, if somebody wants to discuss, and if you want to encourage implementation please "+1" aka thumbsUp this github-post, rather than commenting in your own post-which-says-meToo, since that emails ~700 repo-watchers. Not sure editing my comment will avoid emailing repo-watchers, but with luck it will not :-)

Bug description

When she enables disappearing-messages for her chat or groupchat with Bob, on the conversation-list Alice expects to see Bob near the top, when they have recently conversed. However, after the disappearing-messages timer has expired, the conversation-list entry for the chat/groupchat in question Alice was recently having with Bob, will plummet downward in the sort-order. Even if it was the most-recently-active-conversation for Alice, it will often no longer be at the top of her conversation-list.

If Alice has enough contacts with disappearing-messages enabled, this behavior makes the conversation-list sorting-order (MRU to LRU plus archive-folder) almost useless. Even if she only has just one conversation configured with a short disappearing-messages timer, though, that conversation will regularly be buried somewhere down the conversation-list sort-order.

Note: this github-issue is not related to message-ordering in the chat-history, which is a different bug, it is related to conversation-ordering in the conversation-list. Existing discussions: this one from Dec.2018 signal4android, and another one from Feb.2019 signal4ios.

Steps to reproduce

HH:38 create mini-groupchat with 2 participants, set disappear-timer to 5mins
HH:43 after waiting a little while, and scrolling around a bit to refresh the displays, conversation-lists on both A and B display "5mins" as the lastmod (correct)
HH:43 A sends "m1" to B
HH:43 chat-screen of A shows double-unfilled-checkmarks and 'now' in chat-bubble
HH:43 conv-list of B shows bolded excerpt "m1" (implies double-unfilled-checkmarks) and 'now' as lastmod
HH:46 both screens still claim "now" (cached/incorrectly) ... scrolling around a bit causes them to refresh and say "2min" in chat-bubble and lastmod
HH:47 both screens still claim "2min" (cached/incorrectly) ... scrolling around a bit causes them to refresh and say "4min" in chat-bubble and lastmod
HH:48 both screens still claim "4min" (cached/incorrectly) ... scrolling around a bit causes them to refresh and say "5min" in chat-bubble and lastmod
HH:48 the chat-bubble on A disappears, because the timer there expired
HH:49 conv-list of A shows "12 mins" as the lastmod after hitting backbtn, which is "inaccurate" since the lastmod was only 6mins ago
HH:49 after scrolling around a bit, lastmod on B now says 6min, still bolded "m1" and still indicated there is an unread message
HH:51 after opening the unread message, lastmod on B now says 8min , no longer bolded, no longer indicates there is an unread message
HH:53 after opening the unread message, lastmod on B now says 9min , no longer bolded, no longer indicates there is an unread message
HH:53 sent "m2" from B back to A, lastmod on both A and B again says 'now' (correctly)
HH:55 manually deleted "m2" from device B, lastmod now "11 mins" (should say 1min). over on device A, lastmod is 1min (correct).
HH:56 on device B lastmod now 12 mins (should say 2min). over on device A, lastmod is 2min. ... timeout reached on device B, lastmod changes to 18mins (not 12... not 2)
HH:58 on device B lastmod now 19 mins (should say 3min), over on device A manually deleted newest "R one" while still mostly-unread, then back to conv-list and see "19min" lastmod there as well (should say 3min).

Actual result: Conversion-list assumes that the MRU-ness of each item, can be determined from the timestamps in the chat-bubbles therein, which have not yet been deleted (either via disappearing-messages timer or manually). Conversations with disappearing-messages enabled, pop to the top when a recent message arrives... then after the message is read, a few minutes later when the timer expires, the conversation in question plummets down the conversation-list to an indeterminate location.

Expected result: Conversation-list show which conversation-list items were MRU, using a separately-maintained lastmod timestamp. When a conversation receives a new message, it will pop to the top of the conversation-list. Even after individual chat-bubbles have disappeared within the chat-history, the associate conversation-list item will hold a stable position at the appropriate location of the conversation-list sort-order, based on when the conversation was actually last active (sent or received a message), and will display a lastmod timestamp which corresponds to the most recent such event.

Screenshots

Some signal4ios screenshots are shown here, signal4android was similar result. Let me know if you cannot reproduce the behavior, and I can upload some android-screenshots plus android-debuglogs.

Device info

Device: Alcatel A574BL Android version: 7.1.1 Signal version: 4.34.8

Link to debug log

Captured some debuglogs as part of signal4ios troubleshooting, which has the same basic issue with lastmod-timestamps: conversation-list items periodically re-order themselves when the most recent message hits the disappearing-message timer... at which point the conversation-list item in question drops downwards in the MostRecentlyUsed ordering to a quasi-randomized location in the past. https://github.com/signalapp/Signal-iOS/issues/4143#issuecomment-468656342

signalapp / Signal-Android