fix imports
Fix race conditions on flush actions
Remove default Selector and refactor Reactor.schedule to avoid needless allocation for a new Reactor (not optimum for flatMap / iterative Reactor creation)
Fix leaked change from NoDefaultSelector branch
Merge pull request #314 from reactor/enhancement-NoDefaultSelector-in-reactor

Remove default Selector and refactor Reactor.schedule to avoid needless ...
switch back Reactor schedule extension
Increase timeouts.
Integrated fixes from an issue with reactor-tcp-1.0.0.RELEASE that would leak connections if the connection got unexpectedly dropped and the cleanup/deregistration code didn't get a chance to run. The reconnection code has been rewritten to not rely on the connection registry but to use the reference embedded in the Netty ChannelInboundHandler which should render the references to that connection object unreachable when the channel itself goes out of scope.
Force creation of a new Reactor on each new channel creation to ensure that consumers don't cause back references to hold onto dead channels and prevent their being GC'd.
Formatting tweaks.
Formatting tweaks and change to how close handlers are scheduled.
Normalize code formatting.
Tweaks to the way connections are opened and closed and how events are scheduled on the Reactor when those happen.

Also changed the return type of a TcpClient.close() call to a Boolean to be able to tell whether a connection was closed successfully or not.
Merge pull request #315 from reactor/better-tcpclient-reconnect

Better tcpclient reconnect
#306 Addresses issues with the AsyncAppender by re-implementing the underlying components.

We now queue events using an internal ArrayBlockingQueue and inform subclasses of the AbstractSingleWriterAppender when that happens. The default implementation AsyncAppender now uses the single thread of the superclass to do the appending.

Added an additional implementation called DurableAsyncAppender based on the Java Chronicle. Before queueing an event internally, it logs that event to a Chronicle that will persist if the logging system isn't cleanly shut down. When the appender is restarted, it will iterate through any records in that Chronicle and re-process them through its delegate appenders. This might lead to duplicate log entries but the important thing is that no log events will be lost since everything gets persisted to the Chronicle before being queued to be written to a file, inserted into a database, or what have you.
#306 Added log file deletion to beginning of test.
Use Processor as async single-writer.
Add a little javadoc.
Merge pull request #316 from reactor/fix-306-processor-as-async

Fixes #306 by providing a rewritten AsyncAppender and additional Java Chronicle-based DurableAsyncAppender
Only attempt log file cleanup if the directory exists. Otherwise an error occurs.