* develop: (163 commits)
Fix lint error.
Removes changelog file
Fix PR comment
Adds changelog file
Refactors MessageBubbleView
Updating changelog copy
making use of the fake overrides for testing
extracting the personalization complete emitting to a dedicated function
making use of binding api instead of manual findviewbyid
using consistent method naming for setting the capabilities override
taking the personalization feature flag into account when calculating if personalization is supported - also removes a legacy loading workaround for the account creation step, we're navigating to a new screen AccountCreated so we have to stop the loading
adding changelog entry
using correct label for the avatar capability debug override
forwarding to the profile picture flow when display name changing isn't supported but pictures are when personalising the profile
formatting
dynamically switching the onboarding flow based on the capabilities of the homeserver - when avatars can't be changed we complete the personlisation flow
hiding the toolbar back button and handling system back as take the user home if the display name personalisation is not supported
adding test around account creation via dummy
dynamically changing the account created layout based on if the homeserver supports personalisation
adding entry points for injecting and overriding the homeserver capabilities
...
I was observing cases where builtEvents[modificationIndex] was not
having the same eventId as the udpatedEntity in handleDatabaseChangeSet.
In particular, I observed both cases that
- there was no item in the list yet with the same eventId as the updated
one
- there was an item with the same eventId already in the list, but at a
different position.
Whenever this happened, the timeline would render missing, duplicated,
or swapped messages in the timeline.
Instead of relying on the modificationIndex to be the same for both the
change set and builtEvents, look up the proper index by eventId.
Imagine scenario:
[this] -> [chunkToCheck] -> [lastForwardChunk]
Then, both `isLastForward` checks will not return, and also the `chunkToCheck.doesNextChunksVerifyCondition { it == this }` will return false.
Since both chunks are connected to the last forward chunk, `isMoreRecent()` will still return `true`, which is wrong in this case.
So do not only check if chunkToCheck has this as any of the next chunks, but also the other way round.
