Contact Introduction Backend
This MR allows you to introduce two of your contacts to each other. They both will receive an introduction with an optional message and then can accept or refuse the introduction which is presented as a notification.
When reviewing, I propose to review the individual commits separately as I took great care to split functional independent parts into separate commits. You might also want to have a look at the [Introduction Client Wiki page](https://code.briarproject.org/akwizgran/briar/wikis/IntroductionClient) to better understand what is going on before looking into the actual code.
Protocol sessions and states are not yet deleted and the UI is still missing (#253). In order to practically test this feature, the UI from !122 is needed.
See merge request !116
BQP with QR codes
This MR implements BQP for key agreement over short-range transports. It also implements the Android UI for using BQP with QR codes.
Closes#117.
See merge request !84
The database's transaction lock is reentrant, meaning that a thread that's already holding the lock can acquire it again. This would allow a thread that already has a transaction in progress to start another transaction, which could cause transaction isolation issues and/or lock timeouts on the database's internal locks.
Check that the current thread isn't already holding the lock when starting a transaction.
This Introduction BSP Client uses its own group to communicate with
existing contacts. It uses four types of messages to facilitate
introductions: the introduction, the response, the ack and the abort.
The protocol logic is encapsulated in two protocol engines, one for the
introducer and one for the introducee. The introduction client keeps the
local state for each engine, hands messages over to the engines and
processes the result and state changes they return.
This requires exposing the `containsContact()` method to the `DatabaseComponent`
and is needed for finding out efficiently whether a contact already exists.
Message queues. #266
A message queue is a group shared by two devices that delivers messages from each device to the other in order. The first 64 bits of the message body contain a sequence number that's incremented for each message sent in a given direction. The incoming and outgoing sequence numbers and information about any messages received out of order and waiting to be delivered are stored in the group metadata.
See merge request !121
Fix race condition when closing redundant Bluetooth sockets
The Bluetooth invitation code has a race condition: if Alice and Bob connect to each other at roughly the same time, they each consider their outgoing socket to be redundant and close it, resulting in both sockets being closed. This can be triggered pretty reliably by using two phones of the same model and pressing 'Continue' at the same time on both phones.
When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks, which Bob can detect by trying to read from both sockets.
Hopefully the Bluetooth invitation code will be retired when #117 is merged, but I'm putting this up for review in case we need to keep Bluetooth as a fallback method.
See merge request !120
Delete all app data when deleting account. #263
When deleting the user's account, delete everything in the app's persistent storage directory except the libs directory, which is populated with native libs when the app is installed.
Fixes#263.
See merge request !119
When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks. This fixes a race condition where each party picked a different socket and closed the other.
