Detect unsynchronized second device setup

[hpk42]

It often happens that a user sets up an account on two devices by typing in credentials twice and expects it too work but instead gets undecryptable messages from their own address. We should prevent this situation and guide users to "add second device" setup method instead.

Core needs to detect during (or right after?) configure that this device might be a second but unsynchronized device and should signal this fact to the UI. At best UIs don't even ask for a displayname/avatar but directly advise to cancel the setup and use "add as second device", maybe as a directly clickable button. But this issue here is first of all about detecting the unsynchornized second device during configure. We can probably not unconditionally fail configure but need to give users a choice because it's quite possible that 30 minutes earlier an account was configured but then the app removed, to install it on another device. If nothing else, a device message should be produced and we can iterate on (some/all) UIs then later.

[hpk42]

closing this in favor of #5164 after discussing with @link2xt
basically it seems overly complicated to deal with unsynchronized multi-device during configure, and there is no fail-proof detection -- by comparison #5164 can 100% detect if unsynchronized outgoing messages actually happen.

[link2xt]

The result of discussion is that there are four things we can do:

1. Detect self-sent undecryptable message and a broken setup already in use (Add device chat message when a self-sent undecryptable message is sent #5164). This is the current priority.
2. Detect existing setup during configuration by looking for old outgoing messages with Chat-Version header or Autocrypt header with a different key. This is not as reliable because maybe existing setup is actually deleted and was only used for testing. We also don't fetch messages during configuration and before asking user for the name/avatar currently, so it is more difficult to implement. Currently postponed.
3. Improving handling of incoming undecryptable messages. There are various things we can do to prevent a lot of 1:1 chats popping up if we are in a large group but use a different key now. Some ideas are creating one device message per contact and displaying in the profile that contact recently sent an undecryptable message, but not spamming 1:1 chats with square bracket errors. These ideas are not ready yet for an actionable issue, maybe can be resurrected after Add device chat message when a self-sent undecryptable message is sent #5164.
4. Prevent setting up second account with the same address on the same device (in the same account manager) or warn about it. Nice to have, but not creating an issue for this.