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
Make BytesValues documentation clearer about BytesRef ownership.
batch failed shards into a single cluster state event
make sure we process as much as possible failed shard events within a single cluster state event callback (similar to what we do with started shards)
Added a status method CountResponse that resolve shard failures into rest status code. That method is now used in RestCountAction to return proper status.

Closes #3585
Treat empty prefrence as a `not set` in Plain Operation Routing

An empty preference was causing a AIOOB exception in
PlainOperationRouting. We now check for `null` or `empty` instead of
just `null`

Closes #3591
Prevent allocation algorithm from prematurely exiting balance operations

In a special case if allocations from the "heaviest" to the "lighter" nodes is not possible
due to some allocation decider restrictions like zone awareness. if one zone has for instance
less nodes than another zone so one zone is horribly overloaded from a balanced perspective but we
can't move to the "lighter" shards since otherwise the zone would go over capacity.

Closes #3580
Migrated documentation into the main repo
Temp