This commit makes reactions in the status timeline work.
There are two things prior to this commit that are broken:
1. The logic that opens the reaction context menu always expects
and instance of `chatsView` because it tries to calculate a users
nickname. Such an instance isn't always available in that context, so
the nickname logic has been moved to `appMain` for now, removing that
dependency and therefore making it work in both, the chat view as well
as the status view.
2. While 1) makes the context menu work, it turns out that adding and
removing reactions inside the status timeline is still not working.
The reason for that is, that the reactions component maintains its own
`messageList`, which isn't aware of the fact that reactions for messages
coming from chats of `ChatType.Profile`, need to go into a dedicated
message list for `ChatType.Timeline`.
In other words, reactions are sent and removed from message in messagelists
that don't actually exist.
This commit fixes both of these things by ensuring the message lists
maintained by reactions are timeline aware. Also ensuring updates are
done correctly.
Prior to this commit, the function was expected on a `chatView` QML object.
This has worked out so far because the places where the API is used were always
living inside `ChatLayout`.
With the new timeline however, this is no longer the case so we have to make sure
that the API is available to other views as well.
This is needed when accessing the context menu from the timeline status updates.
Previously, it'd only change the active channel because it assumed the user is already
in the chat view. This is no longer the case when in timeline view, so we need to make sure
we first navigate to the chat view.
We've introduced a bug in https://github.com/status-im/nim-status-client/commit/8fd28dfa where a
non-existing `UnblockContactConfirmationDialog` usage was added.
This commit changes it to be a standard `ConfirmationDialog` to make the application compile
again.
This PR is a response to @emizzle's suggested change in PR #1431 . It checks if a user is blocked before exposing certain functionality to the user in a Profile popup. The new unblock button also has a fail-safe unblock confirmation popup
disable the chat input if 1-on-1 chat recipient has been blocked.
