ArgumentExceptions in FieldResolver bubble out as UnexpectedElasticsearchClientExceptions

[gmarz]

The underlying exception is an ArgumentException and it should bubble out as an ElasticsearchClientException. The problem lies in the fact that .Resolve() is called later in the pipeline.

[russcam]

As per discussion earlier, we will defer the field naming conventions to Elasticsearch; this way, if Elasticsearch's naming conventions change we do not also need to reflect these changes in the client, duplicating effort.

I will add tests to assert that the server error returned indicates the cause of the error.

[russcam]

We still potentially have a problem with ArgumentException being thrown here

[gmarz]

Hmm...yea. Maybe throwing a ResolveException is the better choice then.

/cc @Mpdreamz

[gmarz]

Going to bump this for now and release 2.0.5 without it. It's low priority anyway.

[Mpdreamz]

I kinda like ResolveException allows us to keep the door open to introduce client side validation of indexnames and fieldnames when these crystalize more in elasticsearch itself.

I would like still throw one for IndexName's with uppercase in them since its such a common mistake.