Sign Introduction Information to be able to discover MITM attack

The local introducee doesn't know whether each piece of information received from the introducer originates from the remote introducee or has been replaced by the introducer, i.e. whether the introducer is carrying out a man-in-the-middle attack.

The introduction protocol doesn't aim to detect or prevent man-in-the-middle attacks. We only aim to establish that if the remote identity public key is not replaced then the remote ephemeral public key, transport properties and timestamp are not replaced either. This MR adds a MAC and a signature to the introduction protocol's ACK message to fulfill that aim. See #364 for the detailed security argument.

Later, when the local introducee verifies that the remote identity public key belongs to a particular person (#513), she can also be sure that the remote ephemeral public key, transport properties and timestamp originated from that person.

Closes #364

See merge request !297

Before the introducee sends her ACK,
she derives a master key from the ephemeral shared secret as before.

Two nonces and a MAC key are then derived from the master key.
The local introducee signs one of the nonces and calculates a MAC
over her own identity public key, ephemeral public key,
transport properties and timestamp.
The local introducee includes the signature and MAC in her ACK.

On receiving the remote introducee's ACK,
the local introducee verifies the signature and MAC.
Should the verification fail, an ABORT is sent to the introducer and
the remote introducee that was added as inactive is deleted again.

The MAC and signature are not yet generated and verified.
This will happen in a later commit.

Fix various notification bugs

Fixes #539, #564, #568.

Depends on !276.

See merge request !286

Add MAC function to crypto component



See merge request !295

Define iteration order of BdfDictionary

Closes #618

See merge request !296

Use Briar's IoUtils.copy(), not H2's IOUtils.copy()

Our implementation closes both streams, H2's implementation leaves them open.

Closes #614.

See merge request !293

Blog controller thread safety

This patch removes the mutable list of posts from the blog controller to make it thread-safe, and adds a cache of message bodies to speed up reloads.

Closes #555.

See merge request !276

Cleanup Gradle and Proguard to fix connectedCheck

Closes #597

See merge request !284

Merge branch '311-audit-crash-report-and-feedback-fields-for-sensitive-or-identifying-information' into 'master'

Remove sensitive information from crash and feedback reports

This depends on MR !290 and removes also the crash report settings.

Closes #311

See merge request !291

Scrub addresses before logging them

MAC, IP and onion addresses are now scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.

* Bluetooth MAC addresses keep the first and last octets
* IPv4 addresses keep the first and last octets
* IPv6 addresses should be scrubbed completely (couldn't test)
* Onion addresses keep the first three characters

If an address is invalid it will not be scrubbed to enable debugging, because it is most likely not sensitive.

Closes #592

See merge request !290

Closes #311

Add feed title to imported entries

Also fixes one bug where a new feed was not saved and improved HTML stripping a bit.

Closes #483

See merge request !287

This also fixes a bug where new feeds was not added properly.

Also fixes one bug where a new feed was not saved and
improved HTML stripping a bit.

Upgrade gradle to 2.14.1 and gradle plugin to 2.1.3.



See merge request !292

Add hidden service address for dev reports

Closes #573

See merge request !289

Server-side code for accepting crash reports and feedback

* Moved some shared code for copying InputStreams to OutputStreams into a utility class
* Modified the  dev report sender to send one report per connection
  * Easier to handle on the server side
  * If the connection fails after sending any reports, they don't need to be resent
  * Tor will reuse the circuit, so it's cheap
* Added server-side code for accepting dev reports
  * We need to protect the server's resources from DoS attacks
  * Reports can't be larger than 1 MB
  * Connections are limited to an average rate of one per minute
  * The rate limiter uses a token bucket to allow bursts of up to 1,000 connections
  * If the rate limit is exceeded, connection attempts will fail - clients will retry next time they sign in
  * The limits can be raised when we move to a bigger server (and when we have some users)


See merge request !288

Stop supporting Gingerbread

Closes #566

See merge request !278

This allows simpler server-side code, and a failure part-way through sending won't require restarting from the beginning next time.