* If the user has already declined, we don't show that the other
  introducee has declined as well. The backend doesn't have that information, so
  this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we show the
  decline response in the private conversation with the introducer. If
  the user hasn't yet responded, we hide the accept/decline buttons
  in the introduction request message.

Messages an introducee receives in a `FINISHED` state are now being
ignored and deleted.

Closes #295

Remove Tor binaries from repo. #203

This patch removes the Tor binaries from the repo - the binaries will be downloaded at build time and verified using SHA-256 hashes included in the repo.

After this branch has been merged I plan to reduce the size of the repo by rewriting the commit history to delete the Tor binaries (and various other cruft that used to live in the repo, such as fonts).

After the history has been rewritten, everyone will need to delete their local repo and clone a fresh copy. I'll send out some warnings beforehand.

See merge request !147

Introduction Integration Tests

This introduces these integration tests for the introduction client:
* normal session where both introducees accept
* normal session where the first introducee declines
* normal session where the second introducee declines
* one session where a contact is introduced to herself
* one session where two identities of the same contact are introduced to each other

I managed to get rid of the non-determinism missing validator problem by properly injecting the eager singletons.

Attention: This is based on !143 which addresses a corner case that is already tested here.

See merge request !139

Addresses two Introduction Corner Cases

* force decline when two of our own identities are introduced to each
  other
* throw away introduction requests to the same identity
  (impossible to trigger from UI)

Closes #284
Closes #294

See merge request !143

* normal session where both introducees accept
* normal session where the first introducee declines
* normal session where the second introducee declines
* one session where a contact is introduced to herself
* one session where two identities of the same contact
  are introduced to each other

This introduces a new IntroductionAbortedEvent to signal when the
protocol was aborted. It is not yet used in the UI.

It closes #276

* force decline when two of our own identities are introduced to each
  other
* throw away introduction requests to the same identity
  (impossible to trigger from UI)

Closes #284

Don't use inverse style for progress bars. #286

Fixes the appearance of progress bars on Gingerbread, no difference on other platforms. Thanks to @str4d for finding the source of the problem.

See merge request !145

Fix flicker when loading contact list

Fixes #297.

See merge request !144

Catch runtime exceptions from QR code decoder. #298



See merge request !146

Unit Tests for the Introduction Client

Please note that I based this MR is on top of the introduction UI in !122, because I needed to do some more refactoring on top of the other refactoring ;) The refactoring and the tests are in two separate commits.

An integration test will be added as a separate MR.

This addresses part of #276.

See merge request !136

This injects the IntroducerManager and the IntroduceeManger for easier testing

Introduction UI

This is the user interface for the new introduction feature as specified by @Megalox in #253.

This will close #253 

See merge request !122

(except refactoring of conversation item classes)

When devices' clocks are out of sync, it is possible that a response is
shown before the request. This commit makes sure that the timestamp of
responses is always later than the last message in the conversation.

Some wording could be misunderstood to thing introductions were
successful even though they were not. That has been clarified.

A new database transaction was created when getting contacts and local
transport properties. This has been changed to re-use the existing
transaction.

Also addresses minor issues found in review.

The code made the assumption that a session state can be identified by
the unique session ID. However, when multiple identities from the same
device are involved, there are two sessions with the same ID running on
the device.

Hence, a second identifying criteria has to be used to uniquely identify
the correct session. Here, the ID of the group was chosen.
Unfortunately, the session state can not be cached easily anymore
leading to a small performance penalty when getting all messages for the
UI.

Show system notification for successful introductions

Don't allow local identities to be added as contacts

Fixes #287

See merge request !137

Connect to new contacts

The motivation for this change was realising that when we add a new contact, if the Tor plugin has finished publishing its descriptor and stopped polling, we'll never try to connect to that contact via Tor. I decided that instead of making a special case for Tor, we should try to connect to new contacts via all transports.

Changes:
* Don't register outgoing connections until we've read the incoming tag - this prevents the connection indicator from blinking when connecting to a contact who's removed us
* Connect to newly activated contacts using all available transports, without waiting for the poller
* Removed device IDs from transport properties, we don't know how we're going to handle multi-device support yet


See merge request !135

This prevents the connection from being registered until the contact responds, which ensures we're actually connected to the contact.

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