Rename multi percolate item actions:
count_percolate -> count
percolate_existing_doc -> percolate
count_percolate_existing_doc -> count

If header contains `id` field, then it will automatically be percolation  an existing document.
No test is simple
Simplified percolate reduce logic and the percolator recovery test
Configurable sort order for missing string values.

This commit allows for configuring the sort order of missing values in BytesRef
comparators (used for strings) with the following options:
 - _first: missing values will appear in the first positions,
 - _last: missing values will appear in the last positions (default),
 - <any value>: documents with missing sort value will use the given value when
   sorting.

Since the default is _last, sorting by string value will have a different
behavior than in previous versions of elasticsearch which used to insert missing
value in the first positions when sorting in ascending order.

Implementation notes:
 - Nested sorting is supported through the implementation of
   NestedWrappableComparator,
 - BytesRefValComparator was mostly broken since no field data implementation
   was using it, it is now tested through NoOrdinalsStringFieldDataTests,
 - Specialized BytesRefOrdValComparators have been removed now that the ordinals
   rely on packed arrays instead of raw arrays,
 - Field data tests hierarchy has been changed so that the numeric tests don't
   inherit from the string tests anymore,
 - When _first or _last is used, internally the comparators are told to use
   null or BytesRefFieldComparatorSource.MAX_TERM to replace missing values
   (depending on the sort order),
 - BytesRefValComparator just replaces missing values with the provided value
   and uses them for comparisons,
 - BytesRefOrdValComparator multiplies ordinals by 4 so that it can find
   ordinals for the missing value and the bottom value which are directly
   comparable with the segment ordinals. For example, if the segment values and
   ordinals are (a,1) and (b,2), they will be stored internally as (a,4) and
   (b,8) and if the missing value is 'ab', it will be assigned 6 as an ordinal,
   since it is between 'a' and 'b'. Then if the bottom value is 'abc', it will
   be assigned 7 as an ordinal since if it between 'ab' and 'b'.

Closes #896
Make sure preference isn't null
Fixed order of parameters when calling byteSizeField and timeValueField methods (introduced with #3432 - support for human readable flag)
Added log info on test finished
Add more tests for Zone Awareness
MultiTermVectorsAction was wrongly registered under mget
Fixed extraction of site plugins downloaded from github, so that we skip the top-level folder and we place the files directly under the _site folder

Closes #3551
Added unit tests or zone awareness
Fix searching while shard is being relocated

Shard relocation caused queries to fail in the fetch phase either with a
`AlreadyClosedException` or a `SearchContextMissingException`.
This was caused by the `SearchService` releasing the `SearchContext`s via the
superfluous call of `releaseContextsForShard()` when the
Recover small files (< 1mb) using a separate threadpool than large files.

Fixes #3576
AwarenessAllocationTests must extend ESTestCase in order to respect AwaitsFix annotations
Refreshing after green so also recovering replicas will be refreshed.
Added `_name` support to queries.

This extends the named filter support from only filters to also queries.

Closes #3581
ElasticsearchAssertions.assertHitCount also checks shard failures
Don't recover a shard if it just failed on this node and wasn't reassigned to this node by master yet.

When recovery of a shard fails on a node, the node sends notification to the master with information about the failure. During the period between the shard failure and the time when notification about the failure reaches the master, any changes in shard allocations can trigger the node with the failed shard to allocate this shard again. This allocation (especially if successful) creates a ripple effect of the shard going through failure/started states in order to match the delayed states processed by master.  Under certain condition, a node involved in this process might generate warning messages: "marked shard as started, but shard has not been created, mark shard as failed".

This fix makes sure that nodes keep track of failed shard allocations and will not try to allocate such shards repeatedly while waiting for the failure notification to be processed by master.
Don't recover a shard if it just failed on this node and wasn't reassigned to this node by master yet.

additional places where we should track failed shards, and call clean as part of the top level calls
no need for flush/optimize