feat: warn for outdated versions after 6 months (#7144)

3 months were proven to be too short some years ago, after that issue,
we went far up to 12 months.
however, 12 months were considered too long after recent discussions :)
so, 6 months seems to be a good compromise.

the warning is still repeated every months and the text is unchanged.

advantage is still that this approach does not require network or
opt-in, and catches really all lazy updaters with few effort, cmp
deltachat/deltachat-desktop#5422

Author: r10s

src/constants.rs

@@ -95,10 +95,10 @@ pub const DC_GCL_ADDRESS: u32 = 0x04;
 pub(crate) const DC_RESEND_USER_AVATAR_DAYS: i64 = 14;
 
 // warn about an outdated app after a given number of days.
-// as we use the "provider-db generation date" as reference (that might not be updated very often)
-// and as not all system get speedy updates,
+// reference is the release date.
+// as not all system get speedy updates,
 // do not use too small value that will annoy users checking for nonexistent updates.
-pub(crate) const DC_OUTDATED_WARNING_DAYS: i64 = 365;
+pub(crate) const DC_OUTDATED_WARNING_DAYS: i64 = 183;
 
 /// messages that should be deleted get this chat_id; the messages are deleted from the working thread later then. This is also needed as rfc724_mid should be preset as long as the message is not deleted on the server (otherwise it is downloaded again)
 pub const DC_CHAT_ID_TRASH: ChatId = ChatId::new(3);

src/tools/tools_tests.rs

@@ -437,11 +437,10 @@ async fn test_maybe_warn_on_outdated() {
     let t = TestContext::new().await;
     let timestamp_now: i64 = time();
 
-    // in about 6 months, the app should not be outdated
-    // (if this fails, provider-db is not updated since 6 months)
+    // in about 3 months, the app should not be outdated
     maybe_warn_on_outdated(
         &t,
-        timestamp_now + 180 * 24 * 60 * 60,
+        timestamp_now + 90 * 24 * 60 * 60,
         get_release_timestamp(),
     )
     .await;