Update docs to refer to 6.8 instead of 6.7 (#43685)

A few places in the documentation had mentioned 6.7 as the version to
upgrade from, when doing an upgrade to 7.0. While this is technically
possible, this commit will replace all those mentions to 6.8, as this is
the latest version with the latest bugfixes, deprecation checks and
ugprade assistant features - which should be the one used for upgrades.

Co-Authored-By: James Rodewig <james.rodewig@elastic.co>

docs/reference/mapping/removal_of_types.asciidoc

@@ -258,7 +258,7 @@ Elasticsearch 6.x::
 
 * The `_default_` mapping type is deprecated.
 
-* In 6.7, the index creation, index template, and mapping APIs support a query
+* In 6.8, the index creation, index template, and mapping APIs support a query
   string parameter (`include_type_name`) which indicates whether requests and
   responses should include a type name. It defaults to `true`, and should be set
   to an explicit value to prepare to upgrade to 7.0. Not setting `include_type_name`
@@ -442,12 +442,12 @@ documents to it using typeless `index` calls, and load documents with typeless
 
 Index creation, index template, and mapping APIs support a new `include_type_name`
 URL parameter that specifies whether mapping definitions in requests and responses
-should contain the type name. The parameter defaults to `true` in version 6.7 to
+should contain the type name. The parameter defaults to `true` in version 6.8 to
 match the pre-7.0 behavior of using type names in mappings. It defaults to `false`
 in version 7.0 and will be removed in version 8.0.
 
-It should be set explicitly in 6.7 to prepare to upgrade to 7.0. To avoid deprecation
-warnings in 6.7, the parameter can be set to either `true` or `false`. In 7.0, setting
+It should be set explicitly in 6.8 to prepare to upgrade to 7.0. To avoid deprecation
+warnings in 6.8, the parameter can be set to either `true` or `false`. In 7.0, setting
 `include_type_name` at all will result in a deprecation warning.
 
 See some examples of interactions with Elasticsearch with this option set to `false`:
@@ -717,12 +717,12 @@ indices.
 [float]
 ==== Mixed-version clusters
 
-In a cluster composed of both 6.7 and 7.0 nodes, the parameter
+In a cluster composed of both 6.8 and 7.0 nodes, the parameter
 `include_type_name` should be specified in indices APIs like index
 creation. This is because the parameter has a different default between
-6.7 and 7.0, so the same mapping definition will not be valid for both
+6.8 and 7.0, so the same mapping definition will not be valid for both
 node versions.
 
 Typeless document APIs such as `bulk` and `update` are only available as of
-7.0, and will not work with 6.7 nodes. This also holds true for the typeless
+7.0, and will not work with 6.8 nodes. This also holds true for the typeless
 versions of queries that perform document lookups, such as `terms`.

docs/reference/upgrade.asciidoc

@@ -7,8 +7,8 @@
 process so upgrading does not interrupt service. Rolling upgrades are supported:
 
 * Between minor versions
-* From 5.6 to 6.7
-* From 6.7 to {version}
+* From 5.6 to 6.8
+* From 6.8 to {version}
 
 {es} can read indices created in the previous major version. If you
 have indices created in 5.x or before, you must reindex or delete them

docs/reference/upgrade/cluster_restart.asciidoc

@@ -5,7 +5,7 @@ To upgrade directly to {es} {version} from versions 6.0-6.6, you must shut down
 all nodes in the cluster, upgrade each node to {version}, and restart the cluster.
 
 NOTE: If you are running a version prior to 6.0,
-https://www.elastic.co/guide/en/elastic-stack/6.7/upgrading-elastic-stack.html[upgrade to 6.7]
+{stack-ref-68}/upgrading-elastic-stack.html[upgrade to 6.8]
 and reindex your old indices or bring up a new {version} cluster and
 <<reindex-upgrade-remote, reindex from remote>>.
 

docs/reference/upgrade/reindex_upgrade.asciidoc

@@ -36,7 +36,7 @@ been deleted.
 [[reindex-upgrade-inplace]]
 === Reindex in place
 
-You can use the Upgrade Assistant in {kib} 6.7 to automatically reindex 5.x
+You can use the Upgrade Assistant in {kib} 6.8 to automatically reindex 5.x
 indices you need to carry forward to {version}.
 
 To manually reindex your old indices in place:
@@ -103,7 +103,7 @@ endif::include-xpack[]
 
 You can use <<reindex-from-remote,reindex from remote>> to migrate indices from
 your old cluster to a new {version} cluster. This enables you move to {version}
-from a pre-6.7 cluster without interrupting service.
+from a pre-6.8 cluster without interrupting service.
 
 [WARNING]
 =============================================
@@ -196,4 +196,4 @@ monitor progress of the reindex job with the <<tasks,task API>>:
   `30s` and `1`).
 
 .. Once reindexing is complete and the status of the new index is `green`,
-  you can delete the old index.
+  you can delete the old index.

docs/reference/upgrade/rolling_upgrade.asciidoc

@@ -10,8 +10,8 @@ running the older version.
 Rolling upgrades are supported:
 
 * Between minor versions
-* {stack-ref-67}/upgrading-elastic-stack.html[From 5.6 to 6.7]
-* {stack-ref-70}/upgrading-elastic-stack.html[From 6.7 to 7.0]
+* {stack-ref-68}/upgrading-elastic-stack.html[From 5.6 to 6.8]
+* {stack-ref-70}/upgrading-elastic-stack.html[From 6.8 to 7.0]
 * From {prev-major-version} to {version}
 
 Upgrading directly to {version} from 6.6 or earlier requires a