Do not reset peerstate if the message is encrypted and signed with the current autocrypt key

[link2xt]

#3778 allows to establish encrypted chat with Thunderbird by sending a message with an attached key from Thunderbird to Delta Chat. But if Thunderbird user then sends an encrypted and signed message without the attached key, Delta Chat will reset Autocrypt peerstate and send the next message unencrypted.

The proposal is to keep Autocrypt state if the message is Autocrypt-encrypted.

This requires changing mimeparser to postpone updating the peerstate until the message is decrypted, because currently we reset the peerstate immediately when we see that there is no Autocrypt header.

cc @iequidoo @hpk42 @missytake

[iequidoo]

The proposal is to keep Autocrypt state if the message is Autocrypt-encrypted.

I believe we should keep the Autocrypt (or encryption) state even if a message is just signed. In the scope of #3778 the encryption is enabled right upon on a receipt of message with a key attachment because in absence of capability of smth like "prefer-encrypt" attribute that's the best we can do (btw, it's worth checking that the message is signed with the attached key). So, i suggest keeping this logic for further communication. Moreover, consider the following scenario:

• A user sends us a message with a key attachment.
• And right after that sends another one like "Forgot to say...", just signed but w/o the key attached.

Obviously, we shouldn't reset the encryption state if this happens.

[link2xt]

Makes sense, also in groups when the user does not have keys of all recipients and can't encrypt because of this, the signature may be an indicator that the user wants to use OpenPGP nevertheless. Whether the message is encrypted or not does not matter then, we can always use the signature as a signal that user has the key and therefore will be able to decrypt our reply.

btw, it's worth checking that the message is signed with the attached key

True, maybe then #3778 logic can be merged with this one so that an attached key is stored as a key with nopreference, but if the message is signed with the current autocrypt key, we set encryption preference to mutual? If the public key is just attached, it does not necessarily mean that the user has a private key, but if the message is signed with this key, then we definitely know that the sender has access to the private key (assuming we only consider simple autocrypt keys, not setups where encryption and signature keys are different which OpenPGP allows).

[iequidoo]

Done, but note that if the message is encrypted, we don't check whether it's signed with an attached key
currently, otherwise a refactoring of the code is needed because for encrypted messages a
signature is checked and discarded first currently. But i think we'll do the refactoring soon so that the code branches for encrypted and unencrypted messages are merged and all cases are covered