TransportMasterNodeOperationAction: retry operation if cluster state version changed while adding a ClusterStateListener

TransportMasterNodeOperationAction forwards incoming requests to the currently known master node. If that fails due to a connection error, a cluster state listener will be added in order to try again when a new master is elected. After the listener is in place, a check was made to see if the master has change *while* the listener was being added so that change will not be missed. The check was not enough as it may be that the same master was re-elected (for example, a network hick up) and thus test will fail even though the re-ellection event was missed. In these cases, the request would timeout unjustly. This commit changes this test to be  more strict and retry if the cluster state version changed during the addition of the listener.

Closes #5499
Merge GeoPoint specific mapping properties

Close #5505
[TEST] Fix rounding error problems in FuzzinessTests
Merge null_value for boolean field and remove include_in_all for boolean field in doc

Close #5502
Fix incorrect return impl in SmileXContent.createParser.

Close #5510
Added update by query api.

The update by query API allows all documents that with the query to be updated with a script.  This feature is experimental.
The update by query works a bit different than the delete by query. The update by query api translates the documents that match into bulk index / delete requests. After the bulk limit has been reached, the bulk requests created thus far will be executed. After the bulk requests have been executed the next batch of requests will be prepared and executed. This behavior continues until all documents that matched the query have been processed. The bulk size can be configured with the *action.updatebyquery.bulk_size* option in the elasticsearch configuration. For example:
`action.updatebyquery.bulk_size=2500`

The commit relates to issue #2230

Example usage
=================================================
Index an example document:
curl -XPUT 'localhost:9200/twitter/tweet/1' -d '
```
{
   "text" : {
      "message" : "you know for search"
    }
}
```

Execute the following update by query command:
curl -XPOST 'localhost:9200/twitter/_update_by_query' -d '
```
{
    "query" : {
        "term" : {
            "message" : "you"
        }
    },
    "script" : "ctx._source.field1 += 1"
}
```
This will yield the following response:
```
{
  "ok" : true,
  "took" : 9,
  "total" : 1,
  "updated" : 1,
  "indices" : [ {
    "twitter" : { }
  } ]
}
```
By default no bulk item responses are included in the response. If there are bulk item responses included in the response, the bulk response items are grouped by index and shard. This can be controlled by the `response` option.

Options
=====================================================
Additional general options in request body:
* `lang`:  The script language.
* `params`: The script parameters.

Query string options
-----------------------------------------------------
* `replication`:  The replication type for the delete/index operation (sync or async).
* `consistency`: The write consistency of the index/delete operation.
* `response`:  What bulk response items to include into the update by query response. This can be set to the following: `none`, `failed` and `all`. Defaults to none. Warning: `all` can result in out of memory errors when the query results in many hits.
* `routing` : Sets the routing that will be used to route the document to the relevant shard.
* `timeout` : Timeout waiting for a shard to become available.
Updated updatebyquery to latest master
Updated to master 2.

Ported the tests to ElasticSearchIntegrationTests
Removed duplicate update code, with UpdateHelper (which get used via bulk api logic)