JVMCBC-72: Use the right scheduler on bootstrap and increase logging.

Motivation
----------
It was discovered that some parts of the bootstrap process where using the
core and IO threads too much while they instead should be moved to the
computations scheduler earlier to free resources.

Increased logging has been added to the bootstrap process so that when
DEBUG is enabled, it is easer to find spots where threading is incorrect.

Modifications
-------------
Changed the schedulers early through observeOn, as well as increased
DEBUG logging verbosity throughout the bootstrap process.

Result
------
Quicker and less error prone bootstrapping, helping with debugging
of stuck bootstrap processes as well.

Change-Id: If167c0f9264cf18a1508a8c24514d917b76345e6
Reviewed-on: http://review.couchbase.org/43474
Reviewed-by: Simon Baslé <simon@couchbase.com>
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
JVMCBC-71: Move Handler Subjects onto different scheduler.

Motivation
----------
When Subjects are emitted from the IO threads, the code needs to make
sure that the following operators (from external code) are never executed
on the IO threads to avoid the risk of stalling.

Modifications
-------------
All exposed Subjects are now properly moved over to the computation scheduler
of the environment. As part of this effort, it was discovered through the test
cases that the subjects had problems with requested backpressure.

As suggested here (https://github.com/ReactiveX/RxJava/wiki/Backpressure), the code
also applies the onBackpressureBuffer operator.

Result
------
Consuming operators and subscribers are not able to block or in any other way mess
with the IO threads from where they are filled.

Change-Id: Ie51ba40550f6520674caad86019ca2ed24b55a34
Reviewed-on: http://review.couchbase.org/43477
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
Reviewed-by: Simon Baslé <simon@couchbase.com>
JVMCBC-74: Upgrade RxJava to 1.0.1 GA

Motivation
----------
RxJava just released 1.0.1 GA, and since this codebase was on release
candidates before this commit makes sure to run the latest version
possible.

Result
------
Depending on RxJava 1.0.1 GA

Change-Id: I9f77757f9fe22080941b5cd408497bc864ab7e5b
Reviewed-on: http://review.couchbase.org/43746
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
JVMCBC-77: KeyValue content and extras need to be retained.

Motivation
----------
When using profiling tools, it was discovered that lots of exceptions
were thrown as part of the writing process, but hidden because a
Void future was used on those IO write operations. This is fixed in a
separate commit (JVMCBC-76).

As part of the investigation, it was discovered that the ByteBufs
referenced (content and extras) need to be manually retained, because
the MessageToMessageEncoder frees them as it sees fit and otherwise
the code ends up in reference count exceptions (double freeing).

Modifications
-------------
Properly retaining extras and/or content when they are set on the
request.

Result
------
No more reference count exceptions as part of the writing process.

Change-Id: Idfd411082014fbcd87cec31ad33cb7acd5740dc1
Reviewed-on: http://review.couchbase.org/43786
Reviewed-by: Simon Baslé <simon@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
JVMCBC-78: Upgrade RxJava to 1.0.2 GA

Motivation
----------
1.0.2 contains an important enhancement which makes sure that
scheduled actions are not interrupting themselves, which reduces
the bookkeeping that the JVM needs to do, leading to better performance
and less GC cycles.

Fore more information, see https://github.com/ReactiveX/RxJava/issues/1913

Modifications
-------------
Updating the dependency.

Result
------
Less bookeeping in the JVM, leading to a more smooth steady state.

Change-Id: I9b62169f66f7490c047867533e321e668d7db9eb
Reviewed-on: http://review.couchbase.org/43824
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
JVMCBC-76: Listen on IO write operations to log failures.

Motivation
----------
If the void promise is used, less GC is produced, but we are loosing
the ability to see if something goes wrong during the write process.

Modifications
-------------
This code add listeners to write operations and logs when they fail. This
provides better insight by the slight penalty of more GC. Those callbacks
should be short-lived though, so they should die young.

In the future, this can be changed based on the debug level used to achieve
greater performance, but for now correctness is more important than the
last drop of performance.

Result
------
Better debugability of write failures.

Change-Id: I3e4f82f9b4cd495a3e4c4b49e8b8970fc785ce78
Reviewed-on: http://review.couchbase.org/43785
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
JVMCBC-79: Only route config request to the node with the service enabled.

Motivation
----------
When an additional bucket is opened (and other nodes are already connected), it
could be the case that the bucket config request for the new bucket is routed
onto a node where the keyvalue service is not enabled yet.

This leads to config requested "routed around" to the wrong node, even when
the service has been properly established on another node. As a result,
the observable is never completed, leading to a Timeout at the user level.

If the openBucket happens quickly one after another, or if the node set is
just correctly sorted by accident (or if there is only one node), this issue
does not show up (since it happens to be the right node).

Modifications
-------------
When the node locator gets the request, it not only checks if the node is
already connected, but also if the request is routed to the correct hostname.

The hostname passed in to the node locator as part of the request is the same
where the service was initiated before by the configuration loader.

Result
------
The bucket config request is always routed to the proper bucket, making sure
an additional openBucket request always succeeds.

Change-Id: If5830059cdb695c2692ad0c6f3373eb30d97a3c9
Reviewed-on: http://review.couchbase.org/43845
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
Reviewed-by: Simon Baslé <simon@couchbase.com>