JCBC-559: Retry View Responses if possible.

Motivation
----------
In various scenarios, the server can respond with non 200-status view responses, especially
during failover and rebalance. To make the client more robust, most of these responses indicate
an automatic retry, but not all of them.

The 1.4* SDK had sophisticated retry logic based on http status codes, as well as looking
into the response bodies if needed, so this changeset brings the same functionality to the
2.0 SDK.

Modifications
-------------
In the asynchronous view response stream, there is now a ViewRetryHandler which will inspect
the response status code and if needed, error the stream with a static exception (to avoid
overhead of creating a new one, since its internal only and no stack is needed). This exception
is then captured by an error handler and a retry (after a 10ms delay) is triggered.

Note that all other exceptions will be allowed to pass through, as well as specific error bodies
which have been identified to be "correct" responses and need to bubble up to the user - such
as a missing view.

The current code will retry until it gets a successful response, once a fail fast mode is
implemented there can be an option added to cancel it right away.

Result
------
More resilient error handling when transient server response errors are recieved, especially
during rebalance and failover. The implementation is now on par with what we had in the
1.4 SDK.

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