Delayed encrypted outgoing messages may be sorted above "Messages are end-to-end encrypted"

[iequidoo]

The scenario:

• Alice device#1 sends an encrypted message to Bob while being offline. Bob's contact come from vcard or group or the chat was deleted before, not via just-done secure-join
• Bob sends an encrypted message to Alice while Alice device#1 is still offline. A chat with "Messages are end-to-end encrypted" is created on Alice device#2.
• Alice device#1 goes online and finally sends the message. On device#2 it will be above "Messages are end-to-end encrypted".

Another scenario is not a delayed message, but Alice having Inbox and Sentbox, and Inbox is synced earlier when going online, see tests::verified_chats::test_old_message_4(). It's not clear yet that we want to get rid finally of scanning other folders like Sentbox (e.g. @gerryfrancis reported that this breaks their use case, so probably not), so this is still a valid scenario.

This is fixed by #7180
Related bug: #6064

EDIT: clarified preconditions above in italics

[r10s]

It's not clear yet that we want to get rid finally of scanning other folders like Sentbox

even though maybe not fully rolled out, the not scanning and not watching of Sentbox is decided for now, also in direct communication with @gerryfrancis - so that is not argument for the issue

[r10s]

thanks for the clearer issue description, which i tweaked a bit.

i am able to reproduce that now, however, i consider the issue as being pretty minor. there are lots of things that need happening before having that situation - and then, it is not that bad, there are more situations where the e2ee message is no longer there, clear chat, to begin with. also, there is no "from now on" as in the past.

when we introduced the e2ee message, we were aiming for a simple approach, accepting there are cornercases.

looking at the fix at #7180, which introduces quite some complexity and a migration, it seems even clearer to me that a "won't fix" is better for now. also, after all experience, it seems not so far fetched, that we introduce other issues by that. eg. the "e2ee message" having intially a date in the far past, but also bigger issues may come up, there is no cheap change :)

might totally be, that we change the e2ee message at all, but for now, i'd leave things as is, moving ahead and close the issue and the PR, for now, there are more important actionable items.

putting to resurrection, however