Docs: Removed references to deprecated functionality

* search_type=count
* DFS in term vectors
* Replaced string with text/keyword as appropriate

docs/plugins/analysis-icu.asciidoc

@@ -277,10 +277,11 @@ PUT /my_index
     "user": {
       "properties": {
         "name": { <1>
-          "type": "string",
+          "type": "text",
           "fields": {
             "sort": { <2>
-              "type":     "string",
+              "type":      "text",
+              "fielddata": true,
               "analyzer":  "german_phonebook"
             }
           }

docs/plugins/mapper-attachments.asciidoc

@@ -141,7 +141,7 @@ The metadata supported are:
 
 They can be queried using the "dot notation", for example: `my_attachment.author`.
 
-Both the meta data and the actual content are simple core type mappers (string, date, …), thus, they can be controlled
+Both the meta data and the actual content are simple core type mappers (text, date, …), thus, they can be controlled
 in the mappings. For example:
 
 [source,js]
@@ -171,7 +171,7 @@ PUT /test/person/_mapping
 
 In the above example, the actual content indexed is mapped under `fields` name `content`, and we decide not to index it, so
 it will only be available in the `_all` field. The other fields map to their respective metadata names, but there is no
-need to specify the `type` (like `string` or `date`) since it is already known.
+need to specify the `type` (like `text` or `date`) since it is already known.
 
 [[mapper-attachments-copy-to]]
 ==== Copy To feature
@@ -189,13 +189,13 @@ PUT /test/person/_mapping
         "type": "attachment",
         "fields": {
           "content": {
-            "type": "string",
+            "type": "text",
             "copy_to": "copy"
           }
         }
       },
       "copy": {
-        "type": "string"
+        "type": "text"
       }
     }
   }
@@ -222,7 +222,7 @@ PUT /test/person/_mapping
         "type": "attachment",
         "fields": {
           "content_type": {
-            "type": "string",
+            "type": "text",
             "store": true
           }
         }
@@ -343,7 +343,7 @@ PUT /test/person/_mapping
         "type": "attachment",
         "fields": {
           "content": {
-            "type": "string",
+            "type": "text",
             "term_vector":"with_positions_offsets",
             "store": true
           }

docs/plugins/mapper-murmur3.asciidoc

@@ -46,7 +46,7 @@ PUT my_index
     "my_type": {
       "properties": {
         "my_field": {
-          "type": "string",
+          "type": "keyword",
           "fields": {
             "hash": {
               "type": "murmur3"

docs/reference/docs/termvectors.asciidoc

@@ -78,13 +78,6 @@ omit :
  * sum of total term frequencies (the sum of total term frequencies of
    each term in this field)
 
-[float]
-==== Distributed frequencies
-
-Setting `dfs` to `true` (default is `false`) will return the term statistics
-or the field statistics of the entire index, and not just at the shard. Use it
-with caution as distributed frequencies can have a serious performance impact.
-
 [float]
 ==== Terms Filtering
 
@@ -118,7 +111,7 @@ The following sub-parameters are supported:
 
 The term and field statistics are not accurate. Deleted documents
 are not taken into account. The information is only retrieved for the
-shard the requested document resides in, unless `dfs` is set to `true`.
+shard the requested document resides in.
 The term and field statistics are therefore only useful as relative measures
 whereas the absolute numbers have no meaning in this context. By default,
 when requesting term vectors of artificial documents, a shard to get the statistics
@@ -374,8 +367,7 @@ Response:
 
 Finally, the terms returned could be filtered based on their tf-idf scores. In
 the example below we obtain the three most "interesting" keywords from the
-artificial document having the given "plot" field value. Additionally, we are
+artificial document having the given "plot" field value. Notice
-asking for distributed frequencies to obtain more accurate results. Notice
 that the keyword "Tony" or any stop words are not part of the response, as
 their tf-idf must be too low.
 
@@ -388,7 +380,6 @@ GET /imdb/movies/_termvectors
     },
     "term_statistics" : true,
     "field_statistics" : true,
-    "dfs": true,
     "positions": false,
     "offsets": false,
     "filter" : {

docs/reference/modules/painless.asciidoc

@@ -127,7 +127,7 @@ GET /hockey-stats/_search
   },
   "sort": {
     "_script": {
-      "type": "string",
+      "type": "keyword",
       "order": "asc",
       "script": {
         "lang": "painless",

docs/reference/search/profile.asciidoc

@@ -343,7 +343,7 @@ For reference, the various collector reason's are:
 `search_count`::
 
     A collector that only counts the number of documents that match the query, but does not fetch the source.
-    This is seen when `size: 0` or `search_type=count` is specified
+    This is seen when `size: 0` is specified
 
 `search_terminate_after_count`::