fix: Ensure that message being sent is added to the bottom (#8027)

[iequidoo]

Before, if the user fixed their clock incorrectly set to the future, they needed to delete
previously sent messages or wait until this future comes again so that new sent messages are added
to the bottom. Strictly speaking, the problem isn't fixable because we don't know if messages were
incorrectly timestamped into the future or they are timestamped correctly and the clock is now
incorrectly set to the past. Anyway, adding messages to the middle of the chat isn't a good way to
inform the user about the problem.
Fix #8027

[link2xt]

This does not look like a fixable bug because you don't know if the message was incorrectly timestamped into the future or the message is timestamped correctly and the clock is now incorrectly set to the past.

This is also not what was reported in #8027. Inventing theoretical cases and fixing them one by one will just result in more complicated logic and more complicated bugs, we tried this with memberlist management and eventually had to throw away all the old logic and redesign it from scratch.

[iequidoo]

This does not look like a fixable bug because you don't know if the message was incorrectly timestamped into the future or the message is timestamped correctly and the clock is now incorrectly set to the past.

Strictly speaking, yes, but for incoming messages this is actually fixed by tweak_sort_timestamp() and i don't understand why for outgoing messages it should be different. This means that tweak_sort_timestamp() is doing the wrong thing because it doesn't limit the message sort timestamp with smeared time. I.e. smth should be fixed to provide consistent behavior for incoming and outgoing messages.

This is also not what was reported in #8027.

In this issue the user set their clock to the past by mistake and was experiencing sent messages added to the middle of the chat. It's not much different from setting the clock to the future by mistake and then fixing it back.

[iequidoo]

If there is a reason why we sort received messages to the bottom (even if the user set their clock to the past), but we shouldn't do this for sent messages, this PR should be closed, but the reason should be documented as a comment at least.

[link2xt]

Let's merge this, it is a bit unfortunate that this adds a rather complicated SQL query but likely fixes the case of active chatting between senders that have clocks desynced by ~10 seconds or so which is somewhat expected (#8088 (comment)).

[link2xt]

Could you add comments like

10, -- InFresh
13, -- InNoticed
...
28, -- OutMdnRcvd

and say that OutDraft is excluded? It is not really possible to see what is happening here without cross-referencing to MessageState and checking what each number means.

[iequidoo]

Added a shorter comment. I think it should be enough, the only reason why message states are explicitly enumerated is making the index work

[iequidoo]

[...] but likely fixes the case of active chatting between senders that have clocks desynced by ~10 seconds or so which is somewhat expected (#8088 (comment)).

I couldn't understand how this fixes the referenced problem. The comment says:

[...] despite you've already sent your message and the client has rendered it, the friend's message (when it is received) suddenly appears above yours.

But this PR only adjusts sent messages to the bottom.

This PR can fix things if a sent message is rendered slowly e.g. because it's big, so before this PR it could appear in the chat above messages just received.

[link2xt]

I couldn't understand how this fixes the referenced problem.

I agree, I thought about the problem the other way round, where your message is sent and appears above, but this cannot actually happen just during active chatting if your clock does not jump back because all already received messages must be in the past as we normally cap the timestamps to not be in the future.