fix(query_row_optional): do not treat rows with NULL as missing rows

[link2xt]

Instead of treating NULL type error
as absence of the row,
handle NULL values with SQL.
Previously we sometimes
accidentally treated a single column
being NULL as the lack of the whole row.

Fixes #5994

[link2xt]

Primary reason for this was a bug where NULL in mime_references of info messages prevented loading the whole row as if the message does not exist. As we skip info messages when trying to find parent message since #6023, the original problem is gone.

add_info_msg_with_cmd does not set mime_references for info messages, this is how they are created.
Not going to fix this as we have to deal with NULL in mime_references anyway and running a migration fixing this seems dangerous as the database may contain a lot of info messages to fix.

While trying to make a test for this one discovered another bug: #6021

[link2xt]

I added one test for ephemeral timer so this can be considered a fix, but otherwise this is mostly a refactoring to prevent more bugs similar to the one fixed in #6023.

[link2xt]

This is the main part of the PR.

[Hocuri]

LGTM, I have 2 non-blocking thoughts

[Hocuri]

Just FTR: It would also be possible to expect an Option<i64> in the Rust code, and then handle it within Rust instead of SQL:

@@ -1402,7 +1402,7 @@ pub(crate) async fn calc_sort_timestamp(
     ) -> Result<i64> {
         let mut sort_timestamp = cmp::min(message_timestamp, smeared_time(context));
 
-        let last_msg_time: Option<i64> = if always_sort_to_bottom {
+        let last_msg_time: Option<Option<i64>> = if always_sort_to_bottom {
             // get newest message for this chat
 
             // Let hidden messages also be ordered with protection messages because hidden messages
@@ -1413,8 +1413,7 @@ pub(crate) async fn calc_sort_timestamp(
                 .query_get_value(
                     "SELECT MAX(timestamp)
                      FROM msgs
-                     WHERE chat_id=? AND state!=?
-                     HAVING COUNT(*) > 0",
+                     WHERE chat_id=? AND state!=?",
                     (self, MessageState::OutDraft),
                 )
                 .await?
@@ -1432,8 +1431,7 @@ pub(crate) async fn calc_sort_timestamp(
                 .query_get_value(
                     "SELECT MAX(timestamp)
                      FROM msgs
-                     WHERE chat_id=? AND hidden=0 AND state>?
-                     HAVING COUNT(*) > 0",
+                     WHERE chat_id=? AND hidden=0 AND state>?",
                     (self, MessageState::InFresh),
                 )
                 .await?
@@ -1441,7 +1439,7 @@ pub(crate) async fn calc_sort_timestamp(
             None
         };
 
-        if let Some(last_msg_time) = last_msg_time {
+        if let Some(Some(last_msg_time)) = last_msg_time {
             if last_msg_time > sort_timestamp {
                 sort_timestamp = last_msg_time;
             }

[iequidoo]

Option::flatten() can also be used to make the code more brief

[link2xt]

I just kept HAVING here, devs have to understand interaction between MIN, MAX and HAVING anyway and it is then easier to read than trying to think about Result<Option<Option<....