Allow multiple BobStates

[r10s]

BobState is currently kept in memory only and there is only one BobState. this has the following disadvantages:

1. if the app is terminated before Alice answers, the secure join will get stale. eg. iOS suspends app in the background already after 30 seconds, usually the memory is restored on coming to foreground again, but that depends: apps may also be terminated already after 30 seconds.
   android may have similar situations, but also a simple user-exit may terminate a handshake unexpectedly, esp. it that runs for several minutes. EDIT this is fixed by #2920

2. since instant success on simple qr-setup-contact #1215 and non-blocking group QR joins #2508 all handshakes run in background and dc_join_securejoin() always returns immediately with the chat-id.
   however, if dc_join_securejoin() is called again before the old one has finished, the old one is aborted (which is already better than showing an error :)

the idea is to target both issues by handling BobState completely in the database, eg. in a separate table, one row per state.

[flub]

https://github.com/deltachat/deltachat-core-rust/blob/5e26b5bfdce8080512bab26cb95703f20b45e872/src/securejoin.rs#L283

This... is no longer true? Is this still the right way to notify the user?

[r10s]

This... is no longer true? Is this still the right way to notify the user?

the comment is wrong, yes. join_securejoin() function is now not much different from creating a chat and works even when both devices are offline.

the end-user is now informed by info-messages added to the corresponding chat, so, from view of the ui, there is nothing more to do anymore.

[flub]

This... is no longer true? Is this still the right way to notify the user?

the comment is wrong, yes. join_securejoin() function is now not much different from creating a chat and works even when both devices are offline.

the end-user is now informed by info-messages added to the corresponding chat, so, from view of the ui, there is nothing more to do anymore.

Ok, I think the error!() call below that line needs to be fixed in that case.

[flub]

Do we want to allow alice to invite bob with multiple QR codes in parallel, e.g. "here join this and this groups". Or do we only want to allow bob to join multiple alices? From a user point of view the latter is probably a weird case that's different to understand.

This matters because if we allow multiple joining processes at the same time we have to know which bit of state to load from the db. The securejoin protocol took care of this on the alice side with an invite code but the bob side doesn't really do this. We can probably amend the protocol a little, e.g. bob sends an additional header which alice needs to send back, but we'd need to think through the security implications.

[r10s]

Do we want to allow alice to invite bob with multiple QR codes in parallel

i think, in the long run, it would be nice if Bob can just scan multiple qr-codes, no matter if they come from the same or from different Alices. usecase could be eg. a gathering prepared by Alice - "scan here and here and here to join the groups 'kitchen', 'chore' and 'fun'" :)

but if the "same Alice" turns out to be complicated and needs adaptions in the protocol, maybe just start with the simpler parts - persistence and allow Bob to scan different Alices. scanning the same Alice again, will abort pervious handshakes with that Alice (as now with all handshakes).

maybe that's already "good enough". in any case it would already be a huge improvement over the current state.

EDIT: and we can iterate from there - maybe we could also serialize different handshakes with the same Alice. that would save some messages as subsequent joins will take the shortcut in the protocol.

[flub]

now that the group chat is created up front, does it make sense to re-direct (some) info messages about the progress and/or failure of joining a group to this chat instead of the 1:1 chat of the inviter? In any case I'll do this separately, but makes sense to think about already.

[r10s]

now that the group chat is created up front, does it make sense to re-direct (some) info messages about the progress and/or failure of joining a group to this chat instead of the 1:1 chat of the inviter?

for Bob, this already happens. for group-joins all info messages go to the group-chat (info messages are added to BobState::chat_id() - that is the group-chat for secure-join or the one-to-one-chat for setup-contact

to reduce noise and to focus on the gist of the scan - joining a group -, the one-to-one chat is not even shown to the user (however, the contact is added and verified, of course) (technically, the one-to-one chat is there, as it is needed for the messages currently, however, unless it was present before, it is not added to the chatlist the user sees)