function_score parser throws exception if both functions:[] and single function given

In addition, add a special warning if the misplaced function is a "boost_factor"
function to avoid confusion of "boost" and "boost_function".

closes #5995
Update JNA to latest version

Updating to this version allows to configure a special JNA directory,
in case the /tmp directory is mounted with the noexec option, as JNA
extracts some data and tries to execute parts of it.

Also updated documentation to clarify mlockall and memory settings as well
as pointing to the new jna.tmpdir system property.

Closes #5493
[DOCS] Added Twitter Storehaus client

Added Twitter Storehaus client
Fix behavior on default boost factor for More Like This.

A boost terms factor of 1.0 is not the same as no boosting of terms.
The desired behavior is to deactivate boosting by default. If the user
specifies any value other than 0, then boosting is activated.

Closes #6021
Do not start a recovery process if the primary shard is currently allocated on a node which is not part of the cluster state

If a source node disconnect during recover, the target node will respond by canceling the recovery. Typically the master will respond by removing the disconnected node from the cluster state, promoting another shard to become primary. This is sent it to all nodes and the target node will start recovering from the new primary. However, if the drop of a node caused the node count to go bellow min_master_node, the master will step down and will not promote shard immediately. When a new master is elected we may publish a new cluster state (who's point is to notify of a new master) which is not yet updated. This caused the node to start a recovery to a non existent node. Before we aborted the recovery without cleaning up the shard, causing subsequent correct cluster states to be ignored. We should not start the recovery process but wait for another cluster state to come in.

Closes #6024
[DOC] Fix typo in function score query documentation.
[TEST] Replace folded blocks with literal blocks

The regex tests are formatted with blocks for readability.  Previously,
they were formatted using folded style blocks (e.g. using `>`). Folded
blocks convert newlines into spaces.  This is problematic for our regex,
since comments can only be terminated with a newline.

Effectively, anything after a comment will be commented out, making many
of the regex "silently pass".

This commit replaces them with scalar-style blocks (e.g. using `|`), which
treats newlines as significant, and thus correctly terminates comments
inside the regex.

Also fixes a regex test (`cat.thread_pool/10_basic.yaml`) that started
to fail after the block was fixed.  The test was missing a `\s+` before
the closing newline.
[TEST] Disable REST tests until #6033 is fixed.
Change default filter cache to 10% and circuit breaker to 60%
The defaults we have today in our data intensive memory structures don't properly add up to properly protected from potential OOM.
The circuit breaker, today at 80%, aims at protecting from extensive field data loading. The default threshold today is too permissive and can still cause OOMs.
 The filter cache today is at 20%, and its too high when adding it to other limits we have, reduce it to 10%, which is still a big enough portion of the heap, yet provides improved safety measure.
 closes #5990
Fix StackOverflowException for long suggestion strings

Changed getFiniteStrings to use an iterative implementation instead of
recursive, so we don't use a Java stack-frame per character for each
suggestion at build & query time.
[TEST] fixed _cat/thread_pool REST tests with local transport, in case the transport port is not available and gets returned as '-'

Re-enabled REST tests suite

Closes #6033
Search might not return on thread pool rejection
When a thread pool rejects the execution on the local node, the search might not return.
This happens due to the fact that we move to the next shard only *within* the execution on the thread pool in the start method. If it fails to submit the task to the thread pool, it will go through the fail shard logic, but without "counting" the current shard itself. When this happens, the relevant shard will then execute more times than intended, causing the total opes counter to skew, and for example, if on another shard the search is successful, the total ops will be incremented *beyond* the expectedTotalOps, causing the check on == as the exit condition to never happen.
The fix here makes sure that the shard iterator properly progresses even in the case of rejections, and also includes improvement to when cleaning a context is sent in case of failures (which were exposed by the test).
Though the change fixes the problem, we should work on simplifying the code path considerably, the first suggestion as a followup is to remove the support for operation threading (also in broadcast), and move the local optimization execution to SearchService, this will simplify the code in different search action considerably, and will allow to remove the problematic #firstOrNull method on the shard iterator.
The second suggestion is to move the optimization of local execution to the TransportService, so all actions will not have to explicitly do the mentioned optimization.
fixes #4887
Restore read/write visibility is PlainShardsIterator.

Change #5561 introduced a potential bug in that iterations that are performed
on a thread are might not be visible to other threads due to the removal of the
`volatile` keyword.

Close #6039
Fix bug in PropertyPlaceholder and add unit tests.

Close #6034
Remove search operation threading option
Search operation threading is an option that is not really used, and current non default implementations are flawed. Handling it also creates quite the complexity in the search handling codebase...
This is a breaking change, but one that is actually a good one, since I haven't seen/heard anybody use it, and if its used, its problematic...
closes #6042
remove jdk6 from travis options for our java 7 supported branches
only test on openjdk 7 on travis, no need to tax it
Cluster State API: Remove index template filtering

The possibility of filtering for index templates in the cluster state API
had been introduced before there was a dedicated index templates API. This
commit removes this support from the cluster state API, as it was not really
clean, requiring you to specify the metadata and the index templates.

Closes #4954
Analyze API: Default analyzer accidentally removed stopwords

The analyze API used the standard analyzer from lucene and therefore removed
stopwords instead of using the elasticsearch default analyzer.

Closes #5974
Remove operation threading from broadcast actions
Similar to search removal, the operation threading options are not really ued, and the default should always be used. This also considerably simplifies the code.
A side affect is that we can now remove the ShardIterator#firstOrNull method, which can cause for sneaky bugs to occur.
closes #6044