[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
Added minimum_should_match to has_child queries with score_mode != none
Inlined code
Decrement parentWeight.remaining before checking min_should_match
Take minShouldMatch into account in equals(), hashCode() and toString()
Renamed min_should_match to minimum_children
Added support for minimum_children in HasChildQueryBuilder
Implemented CountChildrenConstantScoreQuery as a hybrid between
ChildrenConstantScoreQuery and ChildrenQuery.  Intended only
for has_child filter or has_child queries without scoring
when minimum_children > 1 is specified.