non-blocking group QR joins (#2508)

* refactor: cleanup send_handshake_msg()

- rename to send_alice_handshake_msg() as used by Alice only

- remove dead code from Bob
  (Bob's code is at BobState::send_handshake_message() since some time)

- take a contact_id and not a chat_id;
  this makes things less confusing when
  info-messages are put to the final group chat

* always directly return chat-id from dc_join_securejoin()

* take care not to create a group twice

* adapt documentation

* add info-msg on group invites; add inviter directly after creation

* document existing 'joinqr' command in repl tool

* do not create empty one-to-one chats for group-joins

* refactor: cleanup fingerprint_equals_sender()

- the function takes a contact_id directly now.
  before it consumes the first contact of a one-to-one chat -
  which may be easily confused with the group-chat in creation.
  moreover, the conversion contact_id -> chat_id -> contact_id
  is unneeded overhead.

* show info-messages in destination chat for alice

* fingerprint_equals_sender() returns Err on database failure

* tweak documentation

* clarify what an 'unfinished tasks' task is.

* add regression test for create_for_contact_with_blocked()

* rename Blocked::Manually to better fitting Blocked::Yes

* tweak test_secure_join() and make sure, Alice and Bob have only on chat after a group-join

deltachat-ffi/deltachat.h

@@ -2249,21 +2249,12 @@ char*           dc_get_securejoin_qr         (dc_context_t* context, uint32_t ch
  * This function is typically called when dc_check_qr() returns
  * lot.state=DC_QR_ASK_VERIFYCONTACT or lot.state=DC_QR_ASK_VERIFYGROUP.
  *
- * Depending on the given QR code,
- * this function may takes some time and sends and receives several messages.
- * Therefore, you should call it always in a separate thread;
- * if you want to abort it, you should call dc_stop_ongoing_process().
+ * The function returns immediately and the handshake runs in background,
+ * sending and receiving several messages.
+ * During the handshake, info messages are added to the chat,
+ * showing progress, success or errors.
  *
- * - If the given QR code starts the Setup-Contact protocol,
- *   the function typically returns immediately
- *   and the handshake runs in background.
- *   Subsequent calls of dc_join_securejoin() will abort unfinished tasks.
- *   The returned chat is the one-to-one opportunistic chat.
- *   When the protocol has finished, an info-message is added to that chat.
- * - If the given QR code starts the Verified-Group-Invite protocol,
- *   the function waits until the protocol has finished.
- *   This is because the protected group is not opportunistic
- *   and can be created only when the contacts have verified each other.
+ * Subsequent calls of dc_join_securejoin() will abort previous, unfinished handshakes.
  *
  * See https://countermitm.readthedocs.io/en/latest/new.html
  * for details about both protocols.
@@ -2273,10 +2264,8 @@ char*           dc_get_securejoin_qr         (dc_context_t* context, uint32_t ch
  * @param qr The text of the scanned QR code. Typically, the same string as given
  *     to dc_check_qr().
  * @return Chat-id of the joined chat, the UI may redirect to the this chat.
- *     If the out-of-band verification failed or was aborted, 0 is returned.
+ *     On errors, 0 is returned, however, most errors will happen during handshake later on.
  *     A returned chat-id does not guarantee that the chat is protected or the belonging contact is verified.
- *     If needed, this be checked with dc_chat_is_protected() and dc_contact_is_verified(),
- *     however, in practise, the UI will just listen to #DC_EVENT_CONTACTS_CHANGED unconditionally.
  */
 uint32_t        dc_join_securejoin           (dc_context_t* context, const char* qr);