Do Bluetooth Adapter enabling/disabling in background thread

Also set the default preferences in a background thread when app starts.

Closes #184

See merge request !66

also run setting the default preferences in a background thread

Closes #184

Offer option to uninstall Briar in a panic event (#211)

Due to the nature of how Android app uninstall works without root access, this requires manual confirmation after a panic event was triggered.

See merge request !63

Due to the nature of how Android app install/uninstall works without
root, this requires manual confirmation after a panic was triggered.

Closes #211

Fix notifications for current conversation

* Remove notification about private messages when viewing the conversation
* Do not show a notification for a conversation the user is viewing

Closes #195 

See merge request !61

Remove upstream jar files from all modules except briar-desktop

This also adds a script for running tests without the Android SDK installed

I've tried to find a better way to do this by conditionally including
the briar-android project in settings.gradle, but failed.
Please note that gradle needs to be installed to run the tests by
executing:
```
./run-tests-without-android.sh
```

See merge request !59

I've tried to find a better way to do this by conditionally including
the briar-android project in settings.gradle, but failed.
Please note that gradle needs to be installed to run the tests by
executing:

    gradle test

Please note that this script uses the 'configuration on demand' feature
which is still incubating,
so not every test run is guaranteed to work correctly.
However, there have not been any problems so far.

Do not show messages as unread when the conversation is open

* Only show them as unread when they arrive out of order
* Mark all messages as read when sending a message

Closes #201

See merge request !62

* Only show them as unread when they arrive out of order
* Mark all messages as read when sending a message

Delete database as panic response even when signed out

The method `runOnDbThread()` depends on an executor
that's created by roboguice at startup.
It requires to be signed in, so use a different thread instead.

Closes #215

See merge request !60

The method `runOnDbThread()` depends on an executor
that's created by roboguice at startup.
It requires to be signed in, so use a different thread instead.

Add tests for metadata encoder and parser as well as UTF-8 tests for BDF reader and writer

This also includes a commit to fix issues found in the metadata encoder and parser.

See merge request !58

Use @Test annotation to test for exceptions being thrown (#213)

Please note that this commit only uses the @Test annotation
where exceptions are thrown at the end of the test,
because otherwise the test would not be executed completely.

Examples for this are in DatabaseComponentImplTest where many exceptions
are thrown in close succession or in ConnectionRegistryImplTest where an
exception is thrown in the middle of the test.

Closes #213

See merge request !57

Support for Destructive Panic Actions

This MR is based on and requires !52.

More details are available in the commit message.

All known issues have now been fixed by new upstream releases.

See merge request !54

Initial Support For PanicKit

This MR adds support for the PanicKit libary. It supports the basic default panic response (signing out) which does not require user interaction to work. For destructive panic responses, the user needs to "connect" the panic trigger app (e.g. Ripple) with Briar first. To secure this connection further, TrustedIntents have been added. Gradle Witness is being used to guarantee the integrity of external libraries.

Otherwise, this MR is pretty isolated and should not interfere with other parts of Briar. So merging it should be safe. However, the panic functionality still has rough edges and should not be relied on just now. It will mature along the the PanicKit library and the Ripple app.

Closes #204 


See merge request !52

Please note that this commit only uses the @Test annotation
where exceptions are thrown at the end of the test,
because otherwise the test would not be executed completely.

Examples for this are in DatabaseComponentImplTest where many exceptions
are thrown in close succession or in ConnectionRegistryImplTest where an
exception is thrown in the middle of the test.

PanicKit does distinguish between two kinds of panic responses:

* default responses such as logging out which are non-destructive and
  do not require user interaction, so that the basics work without
  configuration
* destructive responses such as deleting user data. These require
  some sort of authentication to make sure they are not triggered
  by malicious apps

The second type of responses is implemented with this commit.

Authentication is done by comparing the package name
which is very weak. It requires the user to opt-in to
destructive responses and to configure from which app
to receive those (since there might be many different panic
trigger apps).

While possible to uninstall an app and install one with the same
package name afterwards, this always triggers notifications to
the user (if the attacker does not have root access).

Still that is no sufficient security for Briar's requirements,
so that TrustedIntents are used as well to make sure that the
app sending the destructive trigger is signed by a signing key
that we specified before. Currently, that is the one from the
GuardianProject and from IilabEngineering who does the Amnesty
International Panic App.

The responsibility of checking that the panic TRIGGER is
legitimate lies with the app responding to the trigger, so Briar
in this case. This commit checks whether the TRIGGER comes from
a trusted app before performing destructive actions,
but does perform the default action even when triggered from
untrusted apps.

Closes #210

This closes #204

Structured metadata. #112

Task #112 involves defining an interface between the sync protocol and its clients. To avoid the need for clients to keep their own databases, which could get out of step with the sync protocol's database, we're giving clients that ability to store metadata in the sync protocol's database.

Metadata can be associated with any message, channel, or client. Each metadata object is a simple map from strings to byte arrays. We'll provide a simple query interface to retrieve metadata and/or data by specifying a set of metadata keys. Basically we're building a shitty NoSQL database... erm, I mean, an enterprise-grade key-value store.

The basic metadata object is kind of Spartan, so this patch provides an encoder and parser for storing structured metadata. This gives clients an easy way to associate structured data with messages and channels, while leaving them the option of using their own encoding if they prefer.

This MR depends on !49.

See merge request !50

BdfList and BdfDictionary are no longer thread-safe, they require external locking. Metadata (which is the class that will be passed across API boundaries) is still thread-safe.

Transport properties manager facade, key manager refactoring. #112

Refactoring for #112: decouple the invitation and plugin code from the database with a TransportPropertiesManager facade (which will become a BSP client), and move some key management logic from the invitation code to the KeyManager. Update the integration tests to use the new FooManager facades.

See merge request !49

Final crypto changes for BTPv2. #111

This patch brings the implementation into line with the BTPv2 spec. Changes:

* Use BLAKE2s to generate tags
* KDF arguments for key rotation
* Frame IV format

Closes #111.

See merge request !48