Migration 17 depends on Account deserialization, so any migrations that
touch the accounts table need to be applied beforehand.
Re-writing the migration to work directly on the database would lead to
a lot of code duplication, so it's not worth it at this time, but might
become necessary later on to avoid dependency cycles.
If we detect our own ID is not in our own devicelist on receiving an
update, we reannounce ourselves. This used to have the side effect of
modifying the list of devices we thought were in the update set, causing
us to accidentally build a session with ourselves.
This lead to our own key being set to TRUSTED_INACTIVE, resulting in red
lock icons on messages sent by the own device.
We fix this by having publishOwnDeviceId() operate on a copy of the
original set. This commit also includes a db migration which deletes
sessions with oneself and sets own keys back to TRUSTED.
Messages sent from another device of the own account are now explicitly
tagged as carboned message. The session detection logic now uses this
tag to find "session borders".
Moves SQLiteAxolotlStore and XmppAxolotlSession into proper classes.
IdentityKeys trust statuses are now cached in an LruCache to prevent
hammering the database when rendering the UI.
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
Messages are now tagged with the IdentityKey fingerprint of the
originating session. IdentityKeys have one of three trust states:
undecided (default), trusted, and untrusted/not yet trusted.
EditAccountActivity now show own fingerprint, and gives an option to
regenerate local keying material (and wipe all sessions associated with
the old keys in the process).
It also now displays a list of other own devices, and gives an option to
remove all but the current device.
The IDN.toAscii()/IDN.toUnicode() family only namepreps the original
domain passed to it if it contained non-ASCII characters. This means
that for all-ASCII domains, no canonicalization is performed, which
leads to issues like case-sensitivity. This workaround explicitly
namepreps domain parts before calling IDN.toAscii() on them, in order to
get a canonicalized representation (most notably, case invariance). A
basic DB migration is also included.
