Upgrade Elasticsearch version to 2.3

[CCheSumo]

This submission upgrade ES to version 2.3. I was originally trying to upgrade to 5.1 directly. Unfortunately, I had to stop and go for 2.3 due to

• Elasticsearch 5.x requires java 8 and our code base is still at java 7
• Migrate from 1.x to 5.x is not supported in Elasticsearch (Breaking Changes) and AWS [http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-version-migration.html]
• There were many breaking changes that requires api changes between 1.x to 5.x. It will be a big hurdle for users of the library to go from 1.x to 5.x.

The changes in this submission include:

1. Upgrade of elasticsearch version to 2.3 and 5.5
2. Fix breaking changes in index already exists exception
3. Fix breaking changes in document already exists exception
4. Fix breaking changes in delete by query removed from core and became a plugin. AWS does not seem to have this plugin supported though (https://forums.aws.amazon.com/thread.jspa?threadID=247649).
   In this change, if delete by query plugin is enabled, then we can use it. Otherwise, the execution via query, and bulkDelete.

[codecov-io]

Codecov Report

Merging #126 into release-2.0.0 will decrease coverage by 0.11%.
The diff coverage is 33.33%.

@@                 Coverage Diff                 @@
##             release-2.0.0     #126      +/-   ##
===================================================
- Coverage            60.78%   60.66%   -0.12%     
- Complexity              79       80       +1     
===================================================
  Files                   15       15              
  Lines                  923      928       +5     
  Branches               224      226       +2     
===================================================
+ Hits                   561      563       +2     
- Misses                 216      217       +1     
- Partials               146      148       +2

Impacted Files	Coverage Δ	Complexity Δ
...sticsearch_test/ElasticsearchIntegrationTest.scala	0% <0%> (ø)	0 <0> (ø)	⬇️
...sticsearch/restlastic/RestlasticSearchClient.scala	67.07% <44.44%> (-0.86%)	31 <1> (+1)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0985b5e...609722b. Read the comment docs.

[davidcarltonsumo]

So I think this is fine, especially since 1.6 is such an old version.

Having said that, given that the client is pure REST, it seems like we should be able to design it to be able to support multiple different versions, and that we might need to do that. I haven't looked in detail at which classes would have to move, but it feels to me like there's probably a tractable subset of the classes that we could put in packages whose names include a version number, and then we could expose a version of RestlasticSearchClient in that directory that people could use to interact with a specific version and also have a version in its current location that refers to the current version. And then, when we add support for a new version, we could just copy the files from the previous version wholesale to the package for the new version, not trying to be clever about reducing duplication or anything.

I'm not completely sure about the details, admittedly. E.g. #121 changes the state machine, so that makes me not completely confident that we'd be able to do this in a way that limits scope. (I guess the flip side is that it's also not completely obvious to me that it would be awful to copy basically everything when upgrading versions!) And it's not like there are that many serious changes between versions (at least if this plus #121 is representative of version changes), so maybe it's overkill - maybe we could just leave in support for old interfaces as well as new interfaces while using a uniform client. And, finally, there's the test issue - presumably when testing, we would have to specify a single elasticsearch version to test against, which would make it hard to detect regressions against old versions. (Hopefully we could do it in a way to make it easy enough to manually test against old versions, ideally by just temporarily editing one number in the pom, but who knows.)

Anyways, I'm fine merging this specific one, given that there hopefully aren't too many other people on 1.6 and given that we believe that the new version should work with 1.6, it just might be a little less performant. But it feels like something where we'll want to develop a strategy at some point, possibly even for the 5.1 change?

[CCheSumo]

Completely agree on the better support for multiple different versions part. I created an issue #127 for tracking the efforts.

[davidcarltonsumo]

LGTM

[rcoh]

The right answer is to maintain multiple branches for each version -- it's what all the other major ES libraries do. I'd rather not try to extract some shared classes and try to have one piece of code support multiple versions -- given the way we test and build the repo it just isn't pragmatic.

In a world where we were trying to make the best possible public library, we'd maintain a 2.x branch and a 5.x branch. I'm not saying we should necessarily go to that length. Anyone still on 1.x won't be able to use the new releases (full stop). A 1.x branch will be created if it hasn't already to backport changes to 1.x.

LGTM

[rcoh]

See comment below