When receiving a PreKeySignalMessage, then a prekey has been chosen and
should now be removed from the list of available prekeys in the bundle,
so that a different device doesn't choose it as well.
AFAICT, libsignal removes the prekey, so it's then up to us to
regenerate it and republish our bundle.
updates #497
Before these changes, prekeys were stored in two places, one place that
converse-omemo accessed and one that libsignal accessed and when
libsignal deleted a prekey the other store wasn't updated.
Now we let the methods called by libsignal store/remove prekeys (and the
signed_prekey) in the same place as used by the code in converse-omemo.
Instead of setting `active` to `false`, we remove the device entirely
(unless its the current device).
Doing it this way means more fetching of bundles for devices that
disappear and then reappear from a user's devicelist.
However, there might be caching invalidation concerns with just reusing
a cached bundle for a device id that disappeared and then reappears.
Additionally this change simplifies the showing of a contact's device
fingerprints in the modal, since we don't have to take active/inactive
into consideration.
updates #497
and if so, generate a new one.
To do so we have to change the order of events.
1. first we fetch our device list
2. then we generate our bundle info (if necessary)
3. then we update our device list (if necessary)
4. then we publish our bundle
updates #497
