[TEST] Wait for yellow since some shards might not be started

In this test we only index a handful of docs so if we have more shards
than docs we might fail on the `assertSearchResult` since not all shards
are started but results are just fine.
[Query] QueryParser can return null from a query

This causes a NPE since XContentStructure checks if the query is null
and takes this as the condition to parse from the byte source which is
actually null in that case.

Closes #6722
[TEST] assert search results before comparing the results - shards / indices might be missing
[TEST] use existing client that is already in the cluster to wait for joining node
Updated cache.asciidoc

The index level filter cache was removed a long time ago

Closes #6455
[TEST] Order of the results is not important in this test
The query string cache can't return the same instance, since Query is mutable changing the query else where in the execution path changes the instance in the cache too.

Instead the query parser cache should return a cloned instances.

Closes #2542
Closes #6733
Added licence header
[TEST] Reset all cluster if a test hit a failure

Closes #6734
make sure we use the new analyzer wrapper on 4.10
PluginManager: tests for missing plugin name when passing --url

Adding code to test for unset plugin names to fail fast with descriptive error messages. Also simplified the series of `if` statements checking for the commands by using a `switch` (now that it's using Java 7), added tests, and updated random exceptions with the up-to-date flag names (e.g., "--verbose" instead of "-verbose").

Closes #5976.
Closes #6013.
[TEST] mute test - working on a fix
Docs: Link to eskka discovery plugin from doc

Closes #6721
Improve performance for many new fields introduction in mapping
When we have many new fields keep being introduced, the immutable open map we used becomes more and more expensive because of its clone characteristics, and we use it in several places.

The usage semantics of it allows us to also use a CHM if we want to, but it would be nice to still maintain the concurrency aspects of volatile immutable map when the number of fields is sane.

Introduce a new map like data structure, that can switch internally to CHM when a certain threshold is met.

Also add a benchmark class to exploit the many new field mappings use case, which shows significant gains by using this change, to a level where mapping introduction is no longer a significant bottleneck.
closes #6707