Changed GeoEncodingTests to ensure accuracy always >1mm due to rounding errors with very small numbers
REST API: Consistent get field mapping response

If a get field mapping request is issued, and all but the field can be
found, the response should return an empty JSON object instead of a 404.

Closes #4738
mpercolate REST API should support source parameter

As stated in documentation, we should support `?source=` parameter in mpercolate REST operations.

This is how to reproduce it:

```sh
curl -XDELETE "http://localhost:9200/test"

curl -XPUT "http://localhost:9200/test/.percolator/1" -d'
{
    "query" : {
        "match" : {
            "foo" : "bar"
        }
    }
}'

# This one works
curl -XPOST "http://localhost:9200/test/message/_mpercolate" -d '
{"percolate" : {}}
{"doc" : {"foo" : "bar is in foo"}}
'

# This one gives: BroadcastShardOperationFailedException[[test][2] ]; nested: PercolateException[failed to percolate]; nested: ElasticsearchIllegalArgumentException[Nothing to percolate];
curl -XGET "http://localhost:9200/test/message/_mpercolate?source=%7B%22percolate%22%3A%7B%7D%7D%0A%7B%22doc%22%3A%7B%22foo%22%3A%22bar is in foo%22%7D%7D%0A"
```

Closes #4900.
msearch REST API should support source parameter

As stated in documentation, we should support `?source=` parameter in msearch REST operations.

This is how to reproduce it:

```sh
curl -XDELETE "http://localhost:9200/test"

curl -XPOST "http://localhost:9200/test/type/1?refresh" -d'{
    "foo": "bar"
}'

cat requests
{}
{"query" : {"match_all" : {}}}

# This one works
curl -XGET localhost:9200/_msearch --data-binary @requests

# This one gives: {"error":"Failed to derive xcontent from org.elasticsearch.common.bytes.BytesArray@0"}
curl -XGET "http://localhost:9200/test/type/_mget?source=%7B%7D%0A%7B%22query%22%3A%7B%22match_all%22%3A%7B%7D%7D%7D%0A"
```

Closes #4901.
mtermvectors REST API should support source parameter

As stated in documentation, we should support `?source=` parameter in msearch REST operations.

This is how to reproduce it:

```sh
curl -XDELETE "http://localhost:9200/test"

curl -XPOST "http://localhost:9200/test/type/1?refresh" -d'{
    "foo": "bar"
}'

# This one works
curl -XPOST "http://localhost:9200/test/type/_mtermvectors" -d'
{
    "ids" : ["1"]
}'

# This one gives: "ActionRequestValidationException[Validation Failed: 1: multi term vectors: no documents requested;]"
curl -XGET "http://localhost:9200/test/type/_mtermvectors?source=%7B%22ids%22%3A%5B%221%22%5D%7D"
```

Closes #4902.
percolate REST API should support source parameter

As stated in documentation, we should support `?source=` parameter in percolate REST operations.

This is how to reproduce it:

```sh
curl -XDELETE "http://localhost:9200/test"

curl -XPUT "http://localhost:9200/test/.percolator/1" -d'
{
    "query" : {
        "match" : {
            "foo" : "bar"
        }
    }
}'

# This one works
curl -XPOST "http://localhost:9200/test/message/_percolate" -d '{
  "doc" : {
    "foo" : "bar is in foo"
  }
}'

# This one gives: BroadcastShardOperationFailedException[[test][2] ]; nested: PercolateException[failed to percolate]; nested: ElasticsearchIllegalArgumentException[Nothing to percolate];
curl -XGET "http://localhost:9200/test/message/_percolate?source=%7B%22doc%22%3A%7B%22foo%22%3A%22bar%20is%20in%20foo%22%7D%7D"
```

Closes #4903.
Changed p/c benchmarks to use random generated parent ids, index parent and its children in a non deterministic order and let query values match with multiple child / parent documents.
Fix for #4902
Upgrade to Lucene 4.6.1

This upgrade includes a fix for RAM estimation on IndexReader
that allows to expose the amount of used bytes per segment now
as a setting in Elasticsearch. (LUCENE-5373)

Additionally this bugfix release contained a small fix for highlighting
that was already ported to Elasticsearch when reported (LUCENE-5361)

Closes #4897
foreground mode is now the default, s/lets/let's/
Ignore internal errors if JVM can't find the memory pool
Fixed failure for testDeletePercolatorType where the .percolator mapping hasn't propagated to master that was dynamically created via an index call, which made the delete mapping call fail.
Throw exception if an additional field was placed inside the "query" body

Currently the parser accepts queries like

```
"query" : {
     "any_query": {
         ...
     },
     "any_field_name":...
}
```

The "any_field_name" is silently ignored. However, this also causes the parser
not to move to the next closing bracket which in turn can lead to additional query
paremters being ignored such as "fields", "highlight",...
This was the case in issue #4895

closes issue #4895
move to the first field and only then enter for loop