better logic on sending mapping update new type introduction
when an indexing request introduces a new mapping, today we rely on the parsing logic to mark it as modified on the "first" parsing phase. This can cause sending of mapping updates to master even when the mapping has been introduced in the create index/put mapping case, and can cause sending mapping updates without needing to.
 This bubbled up in the disabled field data format test, where we explicitly define mappings to not have the update mapping behavior happening, yet it still happens because of the current logic, and because in our test we delay the introduction of any mapping updates randomly, it can get in and override updated ones.
closes #6669
[TEST] Also wait for fields to have been applied in the mapping in cluster state during teh waitForConcreteMappingsOnAll call

The concrete DocMapper on the master will be updated before the mapping in the cluster state. The DocMapper is updated during the cluster update task. This can lead to occasional assertion failures on the mapping response, because that is based on the mapping the cluster state, which may not yet have been updated. (time window between the DocMapping is updated, but the mapping in the cluster state isn't)
[TEST] Take compatibility version into account for XContentType
randomization

We randomize the XContentType to test deriving the content type on all
APIs. Yet, BWC tests run against versions where CBOR wasn't around
this commit ensures we don't use CBOR when compatibility version is
less than `1.2.0`

Closes #6691
[Discovery] Handle ConnectionTransportException during a Master/Node fault detection ping

Both the Master and Node fault detection register themselves to be notified when a node disconnects to be able to respond to it accordingly. As such, when a ConnectionTransportException was raised on a ping request, it was not handled as it is already handled somewhere else. However, this does introduce a racing condition, if the disconnect  happen during a period where there is no current master (minimum_master_node breach) at which time the fault detection is not active. In this case, we will only discover the disconnect error during the ping request, so we have to respond accordingly.

Closes #6686
[TEST] Don't wait for relocations - the ensureYellow() call does that already
[TEST] Also do waitForConcreteMappingsOnAll() call for the .percolator type.
Percolator: improve logging and cleanup try-catch statement for percolator query loading.
[TEST] use pre 1.2.0 MATCH_ALL version if we test BWC for pre 1.2.0
clean shard bulk mapping update to only use type
today we track both the index name and type for mapping updates in the shard bulk action, but we only work against on index in this level, so no need to track the index name itself
closes #6695
Docs: Fixed missing comma in multi match query example
lightweight minimum master node recovery
don't perform full recovery when minimum master nodes are not met, keep the state around and use it once elected as master
make no master lock an instance var so it can be configured
add rejoin on master gone flag, defaults to false
defaults to false since there is still work left to properly make it work
Make noMasterBlock configurable and added simple test that shows reads do execute (partially) when m_m_n isn't met
Enable `discovery.zen.rejoin_on_master_gone` setting in DiscoveryWithNetworkFailuresTests only.
Changed the default for the 'rejoin_on_master_gone' option from false to true in zen discovery.
Added AwaitFix for the FullRollingRestartTests.
If available newly elected master node should take over previous known nodes.
Fixed compile error
Do not start a recovery process if the primary shard is currently allocated on a node which is not part of the cluster state

If a source node disconnect during recover, the target node will respond by canceling the recovery. Typically the master will respond by removing the disconnected node from the cluster state, promoting another shard to become primary. This is sent it to all nodes and the target node will start recovering from the new primary. However, if the drop of a node caused the node count to go bellow min_master_node, the master will step down and will not promote shard immediately. When a new master is elected we may publish a new cluster state (who's point is to notify of a new master) which is not yet updated. This caused the node to start a recovery to a non existent node. Before we aborted the recovery without cleaning up the shard, causing subsequent correct cluster states to be ignored. We should not start the recovery process but wait for another cluster state to come in.
RoutingService background reroute task should check if node is still master when its run

It may be that between the moment the task was added to the queue the current node stepped down from being master (due to minimum_master_nodes settings).