Bulk: Failed preparsing does not fail whole bulk request

If a preparsing of the source is needed (due to mapping configuration,
which extracts the routing/id value from the source) and the source is not
valid JSON, then the whole bulk request is failed instead of a single
BulkRequest.

This commit ensures, that a broken JSON request is not forwarded to the
destination shard and creates an appropriate BulkItemResponse, which
includes a failure.

This also implied changing the BulkItemResponse serialization, because one
cannot be sure anymore, if a response includes an ID, in case it was not
specified and could not be extracted from the JSON.

Closes #4745
Cluster state toXContent serialization only returns needed data

In order to make sure, that only the requested data is returned to the client,
a couple of fixes have been applied in the ClusterState.toXContent() method.
Also some tests were added to the yaml test suite

Closes #4885
move msearch to use atomic array instead of synchronize
[TEST] Improved IndexAliasesTests

more assertAcked, removed TODO and needless sleep
Improved CreateIndexRequest and CreateIndexRequestBuilder javadocs
[TEST] Added REST tests for create index api
Add missing PHRASE flag for simple_query_string

Closes #4911
Percolator response now always returns the `matches` key.

Closes #4881
[DOCS] unified index settings info and added warmers section in create index docs
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