fix: Make calc_sort_timestamp() a continuous function of message timestamp and improve its performance

[iequidoo]

Depends and based on #7116

fix: Make `calc_sort_timestamp()` a continuous function of message timestamp

This also simplifies the SQL query in `calc_sort_timestamp()` and prepares for creation of a db
index for it so that it's fast. Currently it doesn't uses indexes effectively; if a chat has many
messages, it's slow, i.e. O(n).

This as well fixes ordering of delayed encrypted outgoing messages; before, they could be sorted
above "Messages are end-to-end encrypted."

---

feat: Add timestamp to msgs_index7 to employ it in calc_sort_timestamp()

Tested on some random chat, the SQL query took 1.411202ms (vs 6.692714ms before) in median. Still
looks a bit slow, but already better.

Fix #7308

[iequidoo]

This reply is already encrypted, so now the message order looks more correct as to me. If an old delayed message arrives, even if it's outgoing, e.g. from another device, it also will be sorted correctly

[Hocuri]

So, which problem does this fix? If it fixes an issue, please open an issue for it and link to it. Or does it make something faster, if so, what?

[iequidoo]

So, which problem does this fix? If it fixes an issue, please open an issue for it and link to it. [...]

There's a PR description:

This as well fixes ordering of delayed encrypted outgoing messages; before, they could be sorted
above "Messages are end-to-end encrypted."

I don't think it's correct that encrypted messages can appear above "Messages are end-to-end encrypted." See test_old_message_4() in the first commit, i improved it so that it tests the fix. Also see test-data/golden/two_group_securejoins, the reply from Alice's device is already encrypted. Before, "[email protected] replied" message was above "Messages are end-to-end encrypted." so one could think that it's not encrypted and reveals a part of communication. I'll create an issue, but overall i think that creating issues for things already fixed and just waiting for review isn't helpful. This PR was created before we agreed on more strict rules about creating PRs.

Or does it make something faster, if so, what?

calc_sort_timestamp() is called when adding a new message to the chat, currently it's O(n), i.e. it walks through all messages in the chat. This is not a "scalable chat" approach. If the user doesn't have very "long" chats, the improvement isn't noticeable visually, anyway, improved calc_sort_timestamp() (together with a new db index added in the second commit) saves battery and the new code is much simpler.

[r10s]

closing, see #7308 for reasoning