anchor.diff:  <<search-facets, Facets>> provide a great way to aggregate data within a document set context.
   This context is defined by the executed query in combination with the different levels of filters that can be defined
   (filtered queries, top-level filters, and facet level filters). While powerful, their implementation is not designed
  -from ground up to support complex aggregations and thus limited.
  +from the ground up to support complex aggregations and is thus limited.
   
   .Are facets deprecated?
   **********************************
   As the functionality facets offer is a subset of the one offered by aggregations, over time, we would like to
   see users move to aggregations for all realtime data analytics. That said, we are well aware that such
  -transitions/migrations take time, and for this reason we are keeping the facets around for the time being.
  +transitions/migrations take time, and for this reason we are keeping facets around for the time being.
   Facets are not officially deprecated yet but are likely to be in the future.
   **********************************
   
  
positive.code: === Bucket Aggregations
  
  Bucket aggregations don't calculate metrics over fields like the metrics aggregations do, but instead, they create
  buckets of documents. Each bucket is associated with a criteria (depends on the aggregation type) that determines
  whether or not a document in the current context "falls" in it. In other words, the buckets effectively define document
  sets. In addition to the buckets themselves, the `bucket` aggregations also compute and return the number of documents
  that "fell in" each bucket.
  
  Bucket aggregations, as opposed to `metrics` aggregations, can hold sub-aggregations. These sub aggregations will be
  aggregated for the buckets created by their "parent" bucket aggregation.
  
  There are different bucket aggregators, each with a different "bucketing" strategy. Some define a single bucket, some
  
negative.code: 
  Some aggregations work on values extracted from the aggregated documents. Typically, the values will be extracted from
  a specific document field which is set using the `field` key for the aggregations. It is also possible to define a
  <<modules-scripting,`script`>> which will generate the values (per document).
  
  When both `field` and `script` settings are configured for the aggregation, the script will be treated as a
  `value script`.  While normal scripts are evaluated on a document level (i.e. the script has access to all the data
  associated with the document), value scripts are evaluated on the *value* level. In this mode, the values are extracted
  from the configured `field` and the `script` is used to apply a "transformation" over these value/s.
  
  ["NOTE",id="aggs-script-note"]
  ===============================
  When working with scripts, the `lang` and `params` settings can also be defined. The former defines the scripting
  language which is used (assuming the proper language is available in Elasticsearch, either by default or as a plugin). The latter
  enables defining all the "dynamic" expressions in the script as parameters, which enables the script to keep itself static
  between calls (this will ensure the use of the cached compiled scripts in Elasticsearch).
  ===============================
  
  Scripts can generate a single value or multiple values per document. When generating multiple values, one can use the
  `script_values_sorted` settings to indicate whether these values are sorted or not. Internally, Elasticsearch can
  perform optimizations when dealing with sorted values (for example, with the `min` aggregations, knowing the values are
  sorted, Elasticsearch will skip the iterations over all the values and rely on the first value in the list to be the
  