Disable bloom filters.

make the "es090" postings format read-only, just to support old segments. There is a test version that subclasses it with write-capability for testing.

Closes #8571

Conflicts:
	docs/reference/indices/update-settings.asciidoc
	src/main/java/org/elasticsearch/index/codec/postingsformat/BloomFilterPostingsFormat.java
	src/main/java/org/elasticsearch/index/codec/postingsformat/Elasticsearch090PostingsFormat.java
	src/main/java/org/elasticsearch/index/codec/postingsformat/PostingFormats.java
	src/test/java/org/elasticsearch/index/codec/postingformat/DefaultPostingsFormatTests.java
	src/test/java/org/elasticsearch/index/codec/postingformat/ElasticsearchPostingsFormatTest.java
	src/test/java/org/elasticsearch/search/suggest/completion/CompletionPostingsFormatTest.java
Update DiskThresholdDecider javadoc

Since v1.3.0, and issue #6201, the default values in code and documentation have been updated to 85% and 90% for low and high watermarks. However, the related javadoc still contains the initial values : this commit fix this.
Aggregations: Fix geohash grid doc counts computation on multi-valued fields.

Close #8512
[CORE] Ensure shards are deleted under lock on close

Today there is a race condition between the actual deletion of
the shard and the release of the lock in the store. This race can cause
rare imports of dangeling indices if the cluster state update loop
tires to import the dangeling index in that particular windonw. This commit
adds more safety to the import of dangeling indices and removes the race
condition by holding on to the lock on store closing while the listener
is notified.
Fix compilation problem
DateMath: Fix semantics of rounding with inclusive/exclusive ranges.

Date math rounding currently works by rounding the date up or down based
on the scope of the rounding.  For example, if you have the date
`2009-12-24||/d` it will round down to the inclusive lower end
`2009-12-24T00:00:00.000` and round up to the non-inclusive date
`2009-12-25T00:00:00.000`.

The range endpoint semantics work as follows:
* `gt` - round D down, and use > that value
* `gte` - round D down, and use >= that value
* `lt` - round D down, and use <
* `lte` - round D up, and use <=

There are 2 problems with these semantics:
* `lte` ends up including the upper value, which should be non-inclusive
* `gt` only excludes the beginning of the date, not the entire rounding scope

This change makes the range endpoint semantics symmetrical.  First, it
changes the parser to round up and down using the first (same as before)
and last (1 ms less than before) values of the rounding scope.  This
makes both rounded endpoints inclusive. The range endpoint semantics
are then as follows:
* `gt` - round D up, and use > that value
* `gte` - round D down, and use >= that value
* `lt` - round D down, and use < that value
* `lte` - round D up, and use <= that value

closes #8424
closes #8556
Fix test failures caused by #8556
Fix wrong error messages in MultiMatchQueryParser.

Also fix a typo in the comment

Close #8597
Fix a typo in a javadoc comment in MapperService.

Close #8575
[TEST] all tests should extend ElasticsearchTestCase
Added utility method to CountRequestBuilder

Allows to add a query to CountRequestBuilder as a XContentBuilder.

Closes #8594