unencrypted quoting of encrypted messages

[r10s]

in an opportunistic chat, currently you cannot quote-reply (swipe-to-reply) to a message message if the quoted message was encrypted and the new message cannot be encrypted.

to reproduce:

• open any opportunistic chat which has at least one encrypted message in
• add a new user where the peerstate is not known, if in doubt, invent a user as [email protected]
• swipe to reply on an encrypted message -> sending will fail

the reason for that issue is the idea that once encrypted text should not be resent as unencrypted.

solutions:

1. regard the idea that "once encrypted text should not be resent as unencrypted" as too strict (drawback: might be considered as weaker security)
2. a better error message or not allowing swipe-to-reply on some messages (drawbacks: still bad ux, may also be some work implementation-wise (wording, returning concrete error, maybe an new alert))
3. allow quote-replies, but do not resend the text (drawback: some work implementation-wise)

as 3. seems to have the fewest drawbacks, here the idea in more detail:

• always allow swipe-to-reply as now
• when sending the messages, always set In-Reply-To as now but check if new_msg==unencrypted, parent_msg=encrypted: only in this case, use a fallback text as [Encrypted quotes not shown in unencrypted messages] - this text will be shown for normal mua and in dc if the receiver has deleted the parent before the reply is received
• when receiving a quote, again check if new_msg==unencrypted, parent_msg=encrypted: in this case, calculate the quote text as usually done on sending and set it to Param::Quote - that way, even if the parent gets deleted later, things will work as usual.

[r10s]

adding this to "1.28 remaining things" - for 1.28 we should at least check if webxdc-status-updates are also affected by this bug (on some level, they're also just replies, and even have a quote-text).

[r10s]

we should at least check if webxdc-status-updates are also affected by this bug

indeed, this issue affected webxdc, however, with #2998 we added an easy workaround. so this issue is no longer that urgent for 1.28.