XmppAxolotlMessage is now entirely responsible for handling encryption
and decryption of messages, only leveraging XmppAxolotlSession as a
packing/unpacking primitive for payload keys.
Removed pseudo-dead session generation code step from prepareMessage
function, as sessions have been created by invoking the
TrustKeysActivity for a while now.
Added prepareKeyTransportMessage function, which creates a message with
no payload. The key that is packed into the header keyElements can then
be used for other purposes (e.g. encrypted file transfer).
We introduce a new trust state: INACTIVE. This state is intended for
old keys that have been removed.
When a TRUSTED device is removed from the PEP devicelist, it's status
will be set to INACTIVE. INACTIVE keys are shown in the UI as greyed
out, non-interactible key rows. Messages are not encrypted for INACTIVE
devices.
When an INACTIVE device reappears in PEP, or a message is received from
an INACTIVE device, it is set back to trusted.
If the contact (or the own account) has keys that have UNDECIDED trust,
we now drop the user into the new TrustKeysActivity, where they have to
decide for each new key whether it should be TRUSTED or UNTRUSTED.
Tag sent messages with own fingerprint, set own fingerprint as always
trusted, include own fingerprint in database trust search, explicitly
reset trust colorfilter
XmppConnectionService.sendMessage() now dispatches messages to the
AxolotlService, where they only are prepared for sending and cached.
AxolotlService now triggers a XmppConnectionService.resendMessage(),
which then handles sending the cached message packet.
This transparently fixes, e.g., handling of messages sent while we are
offline.
Bundles are now fetched on demand when a session needs to be
established. This should lessen the chance of changes to the bundles
occuring before they're used, as well as lessen the load of fetching
bundles.
Also, the message encryption is now done in a background thread, as this
can be somewhat costly if many sessions are present. This is probably
not going to be an issue in real use, but it's good practice anyway.
Daniel Gultsch