The new format is simpler but less efficient for small integers, short
strings and short byte arrays.

Note that this is only the generator part of Fortuna, not the
accumulator. The generator requires a seed, which is provided by a
platform-specific implementation of SeedProvider. On Linux the
implementation reads the seed from /dev/urandom.

If the schema of the database is incompatible with the schema expected
by the code, the database throws a DbSchemaException. LifecycleManager
indicates the error to BriarService, which uses HomeScreenActivity to
show a notification and quit the app.

Offered and requested message IDs are stored in the database rather than
being owned by DuplexConnections. This paves the way for moving to a
simplex transport layer.

The distinction between inbox groups and other groups can be maintained
internally, there's no need to represent it on the wire.

Private messages are now the same as group messages, but groups can be
private or public. When a contact is added, a private group is created
and designated as the inbox for exchanging private messages with the
contact.

This produces a saner user experience when devices have differing
clocks.

The Request packet now contains a list of message IDs, rather than a
bitmap referring to the list of messages IDs in the Offer. This allows
the Request to be understood out of context, e.g. if the Offer and
Request are sent over separate connections or a connection is replayed.

The method used by Commons IO to get the available disk space fails on
Android devices that lack a df binary - use the Android API instead.

This removes the other projects' dependency on the Android API.

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().