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