anchor.diff:  === Dedicated percolator index
   
   Percolate queries can be added to any index. Instead of adding percolate queries to the index the data resides in,
  -these queries can also be added to an dedicated index. The advantage of this is that this dedicated percolator index
  +these queries can also be added to a dedicated index. The advantage of this is that this dedicated percolator index
   can have its own index settings (For example the number of primary and replicas shards). If you choose to have a dedicated
   percolate index, you need to make sure that the mappings from the normal index are also available on the percolate index.
   Otherwise percolate queries can be parsed incorrectly.
  
positive.code: --------------------------------------------------
  
  .Additional supported query string options
  * `routing` - In the case the percolate queries are partitioned by a custom routing value, that routing option make sure
  that the percolate request only gets executed on the shard where the routing value is partitioned to. This means that
  the percolate request only gets executed on one shard instead of all shards. Multiple values can be specified as a
  comma separated string, in that case the request can be be executed on more than one shard.
  
negative.code: }
  --------------------------------------------------
  
  On top of this also a mapping type can be associated with this query. This allows to control how certain queries
  like range queries, shape filters and other query & filters that rely on mapping settings get constructed. This is
  important since the percolate queries are indexed into the `.percolator` type, and the queries / filters that rely on
  mapping settings would yield unexpected behaviour. Note by default field names do get resolved in a smart manner,
  