make one-to-one chats read-only the first seconds of a secure-join

[r10s]

this issue is the outcome of the discussion at #5475: protecting Bob (the joiner) of sending unexpected-unencrypted messages during an otherwise nicely running secure-join.

if things get stuck, however, we do not want to block communication - the chat is just opportunistic as usual, but that needs to be communicated:

1. If Bob's chat with Alice has no messages yet, securejoin is started, and Bob doesn't have Alice's key:
   add info-message Establishing guaranteed e2ee, please wait... and let chat_can_send() return false

2. once the info-message Messages are guaranteed to be e2ee from now on is added, let chat_can_send() return true

3. if after TIMEOUT seconds 2. did not happen, add another info-message Could not yet establish guaranteed e2ee but you may already send a message without ¹ and also let chat_can_send() return true

both, 2. and 3. require the event DC_EVENT_CHAT_MODIFIED being sent out so that UI pick up the change wrt chat_can_send() (this is the same way how groups become updated wrt can-send-changes)

The TIMEOUT should be 10-20 seconds so that we are reasonably sure that the app remains active and receiving also on mobile devices.
If the app is killed during this time then we may need to do step 3 for any pending bob-join chats (right now, bob can only
join one chat at a time, see #2777)

this issue only affects one-to-one chats only - groups already have can_send() set to false until secure join is finished.

idea of this approach is to not clutter UI unnecessarily and to not add additional work to UI.

Footnotes

1. to the exact wording can be refined later, it is mainly to get the flow right for now. at let UI know that a secure-join is ongoing #5475 there was also the suggestion to have different texts for "key there" and "key not there", saying that message may or may not be encrypted, however, that seems tricky as the chat is opportunistic, things may change at any time, so i left that out; but once the flow is there, this can also be refined easily ↩

[adbenitez]

I think showing a chat without the possibility to send is a bit weird for a 1:1 chat, oth if you let the user type, user might just be drafting a message and never even realize there was a time they couldn't send, often the case when user sends unencrypted messages, anyway, is when the verification took more than "some seconds", so I am not 100% sure how useful this is, another option would be to retain the sent message in "pending" state for some more seconds if there is a verification in progress

[r10s]

I think showing a chat without the possibility to send is a bit weird for a 1:1 chat

in practise, it is often only for ~1 seconds, so, user would not even notice that there was a delay while reading the info-message :)

we're doing this for group-joins since "forever",even without timeout

but yeah, there are other possibilities around and were discussed also at #5512, but the approach from above does not require UI (and not esp. in the draft area which is sensible anyways on all platforms) and was regarded as a good+easy start. we can iterate always if this approach turns out to be annoying.

and: also for other approaches we would add the info-messages, some feedback similar to groups just make sense anyways, so large parts of this idea are needed anyways

[iequidoo]

another option would be to retain the sent message in "pending" state for some more seconds if there is a verification in progress

Btw, this option wasn't discussed in #5475 and it also doesn't require UI changes. In fact it implies even less info messages, e.g. "Establishing guaranteed e2ee, please wait..." isn't needed. And the user can draft and send messages w/o any delay. And an extra DC_EVENT_CHAT_MODIFIED isn't needed.

[r10s]

if we retain messages if verification is in progress, this is no guarantee, that verification succeeds

so what to do then without additional ui? we probably again have the situation of unexpected unsent or unexpected unencrypted

maybe the latter is acceptable, idk, at least it will be better than current state - but i also think ppl will continue complaining, so the issue is not closed

for the info messages: we want them in any case to have feedback as for groups

all in all, i still think, hiding-sent is the easier and more comprehensive way to move forward to have a solution in a few days for 1.46. we can always iterate on that as needed

[iequidoo]

Btw, allowing the user to send messages immediately creates a race condition: even if we don't send messages sent by the user before timeout unencrypted, but fail sending instead, we start to send new messages unencrypted after timeout (even if we warn the user with some system message), so the user doesn't really know if the message will go encrypted. So, we must warn the user from the very beginning that messages may go unencrypted. But then i'm not sure it's very useful, probably most of users would prefer to wait for guaranteed e2ee anyway. At least the current solution gives more protection from unexpected behaviour.