Clean up tests

* Broke up ConstantsTest (#280) - the key encoding parts are now in KeyEncodingAndParsingTest, the message encoding parts are in MessageSizeIntegrationTest
* Renamed the other integration tests in briar-android-tests
* Moved the integration tests in briar-android-tests to the top-level package, as they all involve code from multiple packages
* Separated DatabaseExecutorModule from DatabaseModule so we can use a different @DatabaseExecutor in integration tests
* Merged AppModule with AndroidModule (@ernir, this touches code you're working on but I don't think there are any conflicts)
* Renamed some TestUtils methods for consistency
* Used TestUtils.getRandomBytes() where applicable

Fixes #280.

See merge request !133

Services should throw exceptions for startup errors

Fixes #273

See merge request !134

Close transport connection if tag isn't recognised. #281

Factored out common code from various DuplexTransportConnection implementations into an abstract superclass, and changed the logic for closing connections so that connections with unrecognised tags are closed immediately. This prevents deleted contacts from thinking they're connected to us when they're not.

See merge request !132

Create local state for clients at startup. #279

Most of the clients we've written so far use private groups shared with individual contacts and/or a local group that's not shared with anyone. To make it easier to ensure that the necessary groups exist when we need them, this patch allows clients to register startup hooks for creating their local state.

Fixes #279.

See merge request !131

Migrate CrashReportActivity to XML layout

Part of #123.

See merge request !126

Don't allow reentrant transactions

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.

See merge request !127

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 signature covers the forum post body, not the message body.

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.

Save queue state before delivering message. #272

Another attempt to fix #272...

See merge request !125

Transaction isolation. #272

When client transactions were implemented the DB's read-write lock was removed, exposing H2's transaction isolation semantics. The default isolation level is "read committed", which allows concurrent transactions to overwrite each other's updates. This was the cause of #272. Changing H2's isolation level to "serialisable" would have caused other problems.

The solution is to reintroduce the DB's read-write lock. The lock is acquired when starting a transaction and released when committing or rolling back a transaction. (We already use try/finally blocks to ensure every transaction is committed or rolled back.) Read-only transactions can share the lock. To avoid deadlock, transactions must not be started while holding other locks.

This patch adapts the key manager to the new locking rules. The rest of the code was already compliant. Transports are now added to the DB during the startup phase, which allows TransportAddedEvent and TransportRemovedEvent to be deleted.

Fixes #269, fixes #272.

See merge request !124