1. The things we're really trying to protect - contact identities,
message contents, etc - can't be erased from memory because they're
encapsulated inside objects we don't control.

2. Long-term secrets can't be protected by erasing them from memory
because they're stored in the database and the database key has to be
held in memory whenever the app's running.

3. If the runtime uses a compacting garbage collector then we have no
way to ensure an object is erased from memory.

4. Trying to erase secrets from memory makes the code more complex.

Conclusion: Let's not try to protect secrets from an attacker who can
read arbitrary memory locations.

DuplexOutgoingSession flushes its output stream if it's idle for a
transport-defined interval, causing an empty frame to be sent. The TCP
and Tor plugins use a socket timeout equal to twice the idle interval to
detect dead connections.

See bugs #27, #46 and #60.

This fixes some lint warnings and may also fix dev task #102.

The TransportReader/Writer's dispose() method should handle that, and
ConnectionManager is responsible for calling it.

Because that's what it does.

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

Fixed a bug in SimplexMessagingIntegrationTest that should've caught
this.

This should enable us to connect to contacts faster at startup and
whenever a new means of connecting becomes available.

The LAN plugin only accepts IPv4 link-local or site-local addresses.
This rules out LANs that use globally routable addresses (such as UCL),
but also reduces the chances of the LAN plugin making observable
connections across the WAN, which could reveal the social graph.

Both plugins will attempt to reuse the previous address and port only if
there's currently an interface with that address; this will avoid
unnecessary attempts to bind to nonexistent addresses.