fix check on which settings to change on
allow to access the global node settings in a static manner
Fix race condition in adding TimeoutClusterStateListener

Fixes #2658
add our own bloom filter implementation
uses more hash iterations, yet require less memory for the same fpp
relates to #2411
Expose CJKWidthTokenFilter and CJKBigramTokenFilter

Closes #2660
Fixed nested facets with filters.
refactoring getter/setters

Fixes #2657
Added Testcase and BugFix fixing #2626 where GeoShape intersects filter omitted matching docs.

SpatialPrefixTree#recursiveGetNodes uses an optimization that prevents
recursion into the deepest tree level if a parent node in the penultimate
level covers all its children.  This produces a bug if the optimization
happens both at indexing and at query/filter time.

This patch fixes the bug by disabling the optimization at indexing time
(to avoid adding overhead for query-heavy workloads).

See LUCENE-4770 for reference
Remove backported Lucene 4 spatial code in favor of the released version in Lucene 4.1
Added support for sorting by fields inside one or more nested objects.

The sorting by nested field support has the following parameters on top of the already existing sort options:

nested_path - Defines the on what nested object to sort. The actual sort field must be a direct field inside this nested object. The default is to use the most immediate inherited nested object from the sort field.
nested_filter - A filter the inner objects inside the nested path should match with in order for its field values to be taken into account by sorting. Common case is to repeat the query / filter inside the nested filter or query. By default no nested_filter is active.
Either the highest (max) or lowest (min) inner object is picked for during sorting depending on the sort_mode being used. The sort_mode options avg and sum can still be used for number based fields inside nested objects. All the values for the sort field are taken into account for each nested object.

Closes #2662
don't exclude services otherwise es.jar doesn't include the SPI information to load XBloomPostings
Improve stability of testSimpleAwareness test
Improve stability of shardsCleanup test
Make it simpler to determine which version of state was used to calculate health
Improve stability of UpdateNumberOfReplicasTests
Support trailing slashes on plugin _site URLs fix #2654
# Fuzzy Phrase Suggester
The `fuzzy` suggester provides a very convenient API to access word alternatives on token
basis within a certain string distance. The API allows accessing each token in the stream
individually while suggest-selection is left to the API consumer. Yet, often already ranked
/ selected suggestions are required in order to present to the end-user.
Inside ElasticSearch we have the ability to access way more statistics and information quickly
to make better decision which token alternative to pick or if to pick an alternative at all.

This `fuzzy_phrase` suggester adds some logic on top of the `fuzzy` suggester to select entire
corrected phrases instead of individual tokens weighted based on a *bigram-model*. In practice it
will be able to make better decision about which tokens to pick based on co-occurence and frequencies.
The current implementation is kept quite general and leaves room for future improvements.

# API Example

The `fuzzy_phrase` request is defined along side the query part in the json request:

```json
curl -s -XPOST 'localhost:9200/_search' -d {
  "suggest" : {
    "text" : "Xor the Got-Jewel",
    "simple_phrase" : {
      "fuzzy_phrase" : {
        "field" : "body",
        "size" : 2,
        "min_word_len" : 1,
        "bigram_field" : "bigram",
        "lambda" : 2.0,
        "real_word_error_likelihood" : 0.95,
        "confidence_only" : false,
        "max_errors" : 0.5
      }
    }
  }
}
```

The response contains suggested sored by the most likely spell correction first. In this case we got the expected correction
`xorr the god jewel` first while the second correction is less conservative where only one of the errors is corrected. Note, the request
is executed with `error_fraction` set to `0.5` so 50% of the terms can contain misspellings (See parameter descriptions below).

```json
  {
  "took" : 37,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 2938,
    "max_score" : 0.0,
    "hits" : [ ]
  },
  "suggest" : {
    "simple_phrase" : [ {
      "text" : "Xor the Got-Jewel",
      "offset" : 0,
      "length" : 17,
      "options" : [ {
        "text" : "xorr the god jewel",
        "score" : 0.17877324
      }, {
        "text" : "xor the god jewel",
        "score" : 0.14231323
      } ]
    } ]
  }
}
````

# API Parameters

This suggester supports all `fuzzy` suggester parameters as well as the following additional parameters:

* `bigram_field` -the name of the field used to do bi-gram lookups for the bigram language model. If this is not set the suggester will use a unigram langugage model to score corrections.
* `lambda` - weight parameter for the language model propability applied as a `power of` to the word propability. <big>P(W|X) * P(W)<sup>&#955;</sup></big>
* `real_word_error_likelihood` - the likelihood of a term being a misspelled even if the term exists in the dictionary. The default it `0.95` corresponding to 5% or the real words are misspelled.
* `confidence_only` - if `true` only suggestions that score higher than the original phrase are returned.
* `max_errors` - the maximum percentage of the terms that at most considered to be misspellings in order to form a correction. This method accepts a float value in the range `[0..1)` as a fraction of the actual query terms a number `>=1` as an absolut number of query terms. The default is set to `1.0` which corresponds to that only corrections with at most 1 misspelled term are returned.
* `separator` - the separator that is used to separate terms in the bigram field. If not set the whitespce character is used as a separator.
* `candidate_size` - the number of candidates that are generated for each individual query term Low numbers like `3` or `5` typically produce good results. Raising this can bring up terms with higher edit distances. The default is `3`.