Update mapping on master in async manner

Today, when a new mapping is introduced, the mapping is rebuilt (refreshSource) on the thread that performs the indexing request. This can become heavier and heavier if new mappings keeps on being introduced, we can move this process to another thread that will be responsible to refresh the source and then send the update mapping to the master (note, this doesn't change the semantics of new mapping introduction, since they are async anyhow).
When doing so, the thread can also try and batch as much updates as possible, this is handy especially when multiple shards for the same index exists on the same node. An internal setting that can control the time to wait for batches is also added (defaults to 0).

Testing wise, a new support method on ElasticsearchIntegrationTest#waitForConcreteMappingsOnAll to allow to wait for the concrete manifestation of mappings on all relevant nodes is added. Some tests mistakenly rely on the fact that there are no more pending tasks to mean mappings have been updated, so if we see, timing related, failures down later (all tests pass), then those will need to be fixed to wither awaitBusy on the master for the new mapping, or in the rare case, wait for the concrete mapping on all the nodes using the new method.

Note, this change also removes `action.wait_on_mapping_change`, this is an internal setting, and is not recommended to set it. It was used using the old test infrastructure to validate if the problem was due to mapping propagation, but we have a much better infra for this now.
I have a concern regarding batching and the fact that we use the first change object. Since we don't directly access the MappingService we might fail to send a newer version of the doc. I like the change made to `updateMappingOnMaster` to only keep one variant. Maybe we should keep just one which refers to the `type` as string and always resolve the current doc mapper here.