Will currently fail at runtime; requires a public key and a server onion.

Modified the project structure, removed module extension and went instead for a non-complete core dependency graph

Semi-encapsulated the core/api dependency graphs and created a proper structure to load eager singletons

Same exponential backoff approach as Bluetooth.

The polling interval increases exponentially each time polling is unsuccessful, up to a maximum of 60 minutes. The interval is reset to 2 minutes whenever a connection is made and whenever Bluetooth is re-enabled.

Provides a checkbox in the settings view, as well as an event handler to
disable/enable the tor network if the device is not on using the wifi
connection.

Refactors network-enabling code to a separate function. This function
is ran after the network state changes, or the settings change and
will update the status accordingly.

We don't need two separate executors for long-running IO threads.

Tor has a controller command, TAKEOWNERSHIP, and a configuration option,
__OwningControllerProcess, that work together to ensure Tor shuts down
when the controlling process dies and/or disconnects from the control
port. By using them we can avoid creating runaway Tor processes that
have to be killed with hacks.

Of course, not all devices support Bluetooth...

Direct P2P connections between mobile devices are unlikely to work, and
they'd expose the social graph to surveillance.