Lost connection is interpreted as empty FETCH response, but advances uid_next #5009
Description
I have disconnected in the middle of FETCH or something like this, and it resulted in missing messages on both my Desktop accounts which I expected to receive a message and an Android account using the same connection. The message is still in the Inbox and I can see it in Thunderbird, but it was never received in Delta Chat.
Around the time a message should have been received, there are log messages like this:
2023-11-15T08:05:55.672Z core/event INFO "" 1 "src/imap.rs:1415: Starting a full FETCH of message set \"147282:147283\"."
2023-11-15T08:06:34.806Z core/event WARNING "" 1 "src/imap.rs:1487: Missed UID 147282 in the server response."
2023-11-15T08:06:34.834Z core/event WARNING "" 1 "src/imap.rs:1487: Missed UID 147283 in the server response."
2023-11-15T08:06:34.834Z core/event WARNING "" 1 "src/imap.rs:1564: Failed to fetch all UIDs: got 0, requested 2, we requested the UIDs [147282, 147283]."
2023-11-15T08:06:34.835Z core/event INFO "" 1 "src/imap.rs:893: 2 mails read from \"INBOX\"."
2023-11-15T08:06:35.002Z core/event INFO "" 1 "src/scheduler.rs:629: IMAP session supports IDLE, using it."
2023-11-15T08:06:35.002Z core/event INFO "" 1 "src/imap.rs:447: Dropping an IMAP connection."
2023-11-15T08:06:35.003Z core/event WARNING "" 1 "src/scheduler.rs:644: idle: STATUS (UIDNEXT) error for {folder:?}: io: timed out: timed out"
Particular UID I was looking at is 147270 and it is not in any logs at all.
In any case, we should be a bit more careful about advancing uid_next in fetch_new_messages when there is no OK response received in the end of the FETCH command. It looks like we never received the end of the FETCH command, but it was completely ignored and 2 mails read from "INBOX" logged.
#4936 itself is not a direct cause of this bug, we should just look for the correct end of FETCH response and fail hard if there is none (drop the IMAP connection and reconnect).