Feature/deserialize off stream

[Mpdreamz]

This PR implements deserializing straight of the response stream for those json serializers that allow for it.

This changes the low level usage pattern from

var result = client.Call();
var response = result.Deserialize<TypeIWant>();

to

var result = client.Call<DesiredType>();
///result.Response is of type DesiredType

If DesiredType is either string or byte[] the response will simply be read and will skip the deserializer altogether.

A special VoidResponse type exists if you want to skip touching the response stream all together i.e when you only care about the http status code returned.

//response will be of type ElasticsearchResponse<VoidResponse>
var response = client.Call<VoidResponse>(); 
//response.Result == null

When you do not have a DesiredType i.e

var result = client.Call();

result.Response will be a dynamic that you can safely deeply nest on i.e

int? intValue = result.Response.hits.hits[0].myproperty["even_deep].intValue;

This wont throw runtime null binding ref exceptions even if for instance myproperty does not exists.

If you still need to hook into how the response stream turns into your desired T you can subclass the default serializer and provide yours as current.

new ElasticsearchClient(settings, serializer: mySubclassedSerializer)

It can be handy in debug mode to always hold a copy of the response body on your ElasticsearchResponse object for this a new connection configuration toggle is introduced:

var config = new ConnectionConfiguration(uri OR connectionPool)
     .ExposeRawResponse();

now response.ResponseRaw will hold a byte[] copy of the response.

Fixes #522 ping @synhershko

[synhershko]

Looking at this from 30k feet, this looks very good.

My only concern is that I'd move more towards serializers, or ResponseHandlers as I called them earlier, being passed by the client with some default ones already written. By that I'd favor composability over inheritance.

The "safe dynamic" is a great idea - make sure to well-define it if its case sensitive or not.

And last - since ExposeRawResponse is for debug purposes, I'd expose it as a string (with lazy evaluation) and not as byte[], so its easy to access while debugging.