test: Fix flaky test_qr_securejoin_broadcast

[Hocuri]

I assume that the problem is that sometimes, alice2 or fiona doesn't accept alice's smeared timestamp, because calc_sort_timestamp() doesn't allow the timestamp of a received message to be in the future. I tried this patch:

diff --cc src/chat.rs
index 9565437cf,9565437cf..a2e4f97d0
--- a/src/chat.rs
+++ b/src/chat.rs
@@@ -46,6 -46,6 +46,7 @@@ use crate::receive_imf::ReceivedMsg
  use crate::smtp::{self, send_msg_to_smtp};
  use crate::stock_str;
  use crate::sync::{self, Sync::*, SyncData};
++use crate::timesmearing::MAX_SECONDS_TO_LEND_FROM_FUTURE;
  use crate::tools::{
      IsNoneOrEmpty, SystemTime, buf_compress, create_broadcast_secret, create_id,
      create_outgoing_rfc724_mid, create_smeared_timestamp, create_smeared_timestamps, get_abs_path,
@@@ -1212,7 -1212,7 +1213,11 @@@ SELECT id, rfc724_mid, pre_rfc724_mid, 
          received: bool,
          incoming: bool,
      ) -> Result<i64> {
--        let mut sort_timestamp = cmp::min(message_timestamp, smeared_time(context));
++        let mut sort_timestamp = cmp::min(
++            message_timestamp,
++            // Add MAX_SECONDS_TO_LEND_FROM_FUTURE in order to allow other senders to do timesmearing, too:
++            smeared_time(context) + MAX_SECONDS_TO_LEND_FROM_FUTURE,
++        );
  
          let last_msg_time: Option<i64> = if always_sort_to_bottom {
              // get newest message for this chat

...maybe this patch makes sense anyways, but you still get the problem that the message sent by alice2 (i.e. the add-fiona message) will have an earlier timestamp than the message sent by alice, because alice already sent more messages, and therefore has more timesmearing-seconds.

Since all this timesmearing is a bit best-effort right now, I decided to instead just make the test more relaxed.

[iequidoo]

I'm not sure it makes sense to modify calc_sort_timestamp() this way because if some chat member has the clock in the future (even unintentionally), their fresh messages will be sorted to the bottom relatively to others' fresh messages. Maybe it's even better to limit the message timestamp ("Date") by the current system time there

[Hocuri]

To really fix the problem, we could send a serial number together with the timestamp, that distinguishes two messages sent in the same second. But since we haven't gotten complaints about message ordering since some time, let's just leave things as they are.