Add third group visibility state
This branch adds a third group visibility state: each group is either invisible, visible, or shared with respect to each contact.
Invisible means that the contact doesn't see any sign that we subscribe to the group. Visible means that the contact can send us messages in the group, but we won't send the contact messages in the group. Shared means that the contact can send us messages in the group and we'll send the contact any shared messages in the group.
This is a preparatory step for #756. I'll put up another MR with the changes that close that ticket.
See merge request !410
Factor MessageTracker out of BdfIncomingMessageHook
The branch moves the MessageTracker implementation from BdfIncomingMessageHook to a separate class. This will allow the private group invitation client to track messages from classes other than the one that implements the delivery hook.
I've also fixed a couple of bugs, removed some redundant code from the validation manager, and added null-safety annotations (which is how I noticed the bugs).
See merge request !405
Add visibility and OPTIONS button to private group join notices


Closes#732
See merge request !408
Made private group timestamp greater than that of latest message
I did not change `getPreviousMsgId()` to `getPreviousMsgHeader()` because there doesn't seem to be a need for it anymore.
Closes#755
See merge request !409
Add onboarding dialog for revealing contacts screen
This MR is based on !406.

See merge request !407
Add UI for revealing contacts within a private group
This addresses one part of #732. Join notices and onboarding will follow in separate MRs.
Although this MR is technically not based on !402, it does require it to be merged first to compile.

See merge request !406
Mark relationship visible when syncing group with peer
This branch updates the private group invitation protocol to use @grote's new method for marking a contact relationship visible to the group.
I've changed the method slightly because the protocol state machine allows us to leave and re-enter the BOTH_JOINED state (see diagram on #659), so the relationship may already be visible when the method is called. In that case the visibility isn't updated, so we stick with whichever of revealed-by-us and revealed-by-contact happened first.
See merge request !402
Prepare UI for revealing contacts
This changes the visibility of some methods (that need to be accessed from another package), removes unnecessary abstractions and fixes erroneous static import of GroupId constant.
See merge request !404
Add new Exception handler
While working on #732 I again needed to use a `UiResultExceptionHandler` when I actually don't need to return a result. We have some other places in the code like this. So I introduced a `UiExceptionHandler` without the result part and used it where appropriate. While I was touching some classes, I also added the new annotations.
This MR includes another small commit that notifies only on local group messages. Joining a group is a message as well and without this change, you are notified about a new message when you yourself joined your newly created group.
See merge request !403
Add support for revealing contacts to the PrivateGroupManager
This also adds three integration tests and improves some small details here and there in the private group client.
Prerequisite for #732.
See merge request !396
Preserve the order of descriptors in QR code payloads
This fixes a regression caused by my recent changes to the Payload class.
Closes#748
See merge request !399
Don't crash if camera is reopened or surface is recreated
This branch fixes the crash is described in #720, which can be reproduced easily by scanning a QR code and failing to connect (for example, scan a screenshot of a QR code from a device that's no longer listening). When the camera view becomes visible again after trying to connect, its surfaceCreated() callback is called again with the same surface. An IllegalStateException added in !340 causes the crash.
Closes#720
See merge request !397
Make the feed pager respond to events, block notifications
This branch fixes a bug I found while working on #705: FeedPostPagerFragment doesn't start or stop the controller, so it doesn't load newly received posts or block notifications, unlike FeedFragment.
See merge request !398