Both devices try to make outgoing connections and accept incoming
connections simultaneously. This should lead to faster connection
establishment when there are asymmetrical connectivity problems, such as
devices that are unable to receive LAN multicast packets or make
themselves discoverable via Bluetooth.

See issue #3612607.

Partially addresses issue #3611924.

Fixes issue #3612607.

To fix issue #3611966, KeyManagerImpl's handling of TransportAddedEvent
was made asynchronous. This made it possible for a thread to call
KeyManager.endpointAdded() before the KeyManager had asynchronously
handled the TransportAddedEvent from a previous call to
DatabaseComponent.addTransport().

CryptoExecutor and DatabaseExecutor now use bounded thread pools with
unbounded queues, since running too many tasks in parallel is likely to
harm performance; IncomingConnectionExecutor, PluginExecutor and
ReliabilityExecutor use unbounded thread pools with direct handoff,
since their tasks may run indefinitely. There are no longer any bounded
executors, and all executors discard tasks when shutting down, which
fixes issue #3612189.

Responsibility for starting and stopping services has been moved from
BriarService in briar-android to LifecycleManagerImpl in briar-core.
However, BriarService is still responsible for stopping the
Android-specific executors, which is ugly. It would be better if
executors registered themselves with LifecycleManager.

Android doesn't currently store bundles persistently, so it's premature
to protect against accidental information leaks through persistent
bundle storage. Protecting against deliberate information leaks by the
OS is probably futile, so there's currently no need for bundle
encryption.

(Although it isn't possible to create an identity yet...)

The invitation and private messaging UIs are currently broken. Some key
rotation bugs were fixed; others may have been created (unit tests
needed). An encoding for private keys was added. Pseudonyms were moved
out of the messaging package and ratings were moved in.

The UI may access the DB in response to UI or DB events; to maintain a
consistent view of the DB's contents, the tasks performing these
accesses must be prevented from overlapping, and must produce consistent
results if reordered. A single-threaded executor and latches are used to
prevent tasks from overlapping, without blocking non-UI access to the
DB.

Fields in Android UI objects that are accessed from background threads
must be declared volatile. UI objects use data attached to DB events to
avoid DB lookups, which complicates the UI code but should improve
performance.