[reactor-queue] move to chronicle 2.0 #183
Added a random option to generating UUIDs based on recent work done in Spring Messaging to generate message ids. Also added a horserace test to make sure that time-based UUID generation isn't any slower than random generation.
Added helper methods to Promises and Streams to make it more succinct to create Deferreds.

In code, it's common to need to create lots of Promises using a standard pattern:

    Deferred<T, Promise<T>> deferred = Promises.<T>defer().env(env).dispatcher(dispatcher).get();

It's a little less code noise to condense that down into:

    Deferred<T, Promise<T>> deferred = Promises.<T>defer(env, dispatcher);

    ...or even...

    Deferred<T, Promise<T>> deferred = Promises.<T>defer(env);

The problem is most noticable when expanding the T to real types, particularly if those types are also generic. That means you have multiple nested generics signatures just for the deferred, with the T repeated, which gets messy pretty quickly. Anything we can do to cut down on the noise is a Good Thing.
Simplify state and locking of Promise and Composable

This commit addresses the problems detailed in issue #191. It removes
Promise's monitor, and, instead, uses the ReentrantLock from its
superclass, Composable.

The use of hasBlockers has been moved so that it's always read and
written when locked. This should eliminate the possibility of
notifications being missed.

Fields that are always accessed under a lock are no longer declared
volatile.
Merge pull request #192 from wilkinsona/promise-locking

Simplify state and locking of Promise and Composable
Added a sendAndReceive method to TcpConnection.

The purpose of sendAndReceive is to make the common use case of a single connection needing to wait for a response or an error from the peer when sending a message. This method internally creates a Deferred<IN, Promise<IN>> and places it on an internal response Queue, after which it sends the outgoing data. When a response is received from the peer or an exception is reported, a Deferred is popped off the Queue and completed with the value or the exception. It assumes a single thread is using the connection and that responses are received 1-for-1 with requests and that each request will receive a single response or error.

This method won't work for instances when the response is split over multiple messages, as is the case with the Netty HTTP support, which sends responses in a response then content object.
Merge remote-tracking branch 'upstream/master'

Conflicts:
	build.gradle
fix conflict
[reactor-core] OSGi : make net.openhft.chronicle optional #194
Merge pull request #195 from lburgazzoli/master

[reactor-core] OSGi : make net.openhft.chronicle optional #194
Changed the existing send(OUT) method to return a Promise.

To avoid having to create too many Promises that might never get used in a fire-and-forget scenario, I changed the Consumer<Boolean> onComplete to a Deferred<Boolean, Promise<Boolean>>, which can be null. If it's not, then the success value or an exception is fulfilled in the Promise. If it's null, then errors are only reported on the internal events Reactor which can be handled by calling TcpConnection.when(Throwable, Consumer<Throwable>).
Fixes for Resequencer so it passes the tests
Rewrite the IndexedChronicleQueuePersistor to use Chronicle 2.0. Also fixed some bugs by re-working how QueuePersistors are used by the PersistentQueue.

Also added a Codec facility to the QueuePersistor and implemented some codecs like Java serialization, JSON mapping using Jackson, String, and byte[].
Fix the test for a recent change in the connection API.
Checking random failure on CI server.
Remove usage of a global NULL_EVENT because it's dangerous if code sets the key and/or replyTo.
Added Jackson + Afterburner JsonPathSelector implementation for matching JsonPath expressions against key objects.

Internally this is implemented by providing an intelligent JsonProvider for Jackson 2. This means the JsonPathSelector can match against JSON data in the form of a String, a byte[], a Map, a List, or a JsonNode read from ObjectMapper.readTree(json).

Initial benchmark performance tests show about 1.2M selections/sec on a new MacBook Pro. That's considerably less than the ObjectSelector, which can get as much as 18-20M selectors/sec. But the flexibility of being able to assign Consumers based on the values extracted from a single JSON document is probably worth the trade-off if you need that functionality.
Tweak the JsonPathSelector for higher throughput. Now getting throughput for JsonPathSelectors that is very nearly comparable to using the ObjectSelector directly. The more selections that are done, the higher the throughput, but numbers in excess of 20M selections/sec are possible using JsonPath over a POJO.
merge