SPY-161: Cascade op cancellations.

Motivation
----------
When an operation is redistributed (be it because of reconnects
and/or "not my vbucket" responses, it gets cloned. The problem
is that the initial callback always points to the original
operation, not the cloned one. While the clone gets the callback,
the other way round (like cancelling from user-code) will never
trickle through to the cloned ops.

Modifications
-------------
In order to fix this issue, code has been added which connects
the original op with the cloned ones, by keeping a list of
cloned operations in the original op. To prevent overly long
stack in malicious scenarios, an overall clone-cap of 100
clones is introduced. If this cap is reached, the operation
will not be cloned further but cancelled.

Result
------
With this modifications, timeouts and cancellations from user code
will trickle through to the clone operations, prevent issues when
cloned operations are around "forever".

Change-Id: I304534a62202b705d78ca5f775f47afcd6be238a
Reviewed-on: http://review.couchbase.org/34883
Reviewed-by: Michael Nitschinger <michael.nitschinger@couchbase.com>
Tested-by: Michael Nitschinger <michael.nitschinger@couchbase.com>