Mark notable breaking changes for 7.0 (#40478)

This commit adds a tag for each breaking change that could be considered
notable.

Author: jasontedor

docs/reference/migration/migrate_7_0/aggregations.asciidoc

@@ -7,12 +7,14 @@
 
 These `execution_hint` are removed and should be replaced by `global_ordinals`.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== `search.max_buckets` in the cluster setting
 
 The dynamic cluster setting named `search.max_buckets` now defaults
 to 10,000 (instead of unlimited in the previous version).
 Requests that try to return more than the limit will fail with an exception.
+//end::notable-breaking-changes[]
 
 [float]
 ==== `missing` option of the `composite` aggregation has been removed

docs/reference/migration/migrate_7_0/api.asciidoc

@@ -2,6 +2,7 @@
 [[breaking_70_api_changes]]
 === API changes
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Internal Versioning is no longer supported for optimistic concurrency control
 
@@ -14,9 +15,12 @@ while handling a write operation, it may expose a version that will then be reus
 new primary.
 
 Due to that issue, internal versioning can no longer be used and is replaced by a new
-method based on sequence numbers. See <<optimistic-concurrency-control>> for more details.
+method based on sequence numbers. See
+{ref}/optimistic-concurrency-control.html[Optimistic concurrency control] for
+more details.
 
 Note that the `external` versioning type is still fully supported.
+//end::notable-breaking-changes[]
 
 [float]
 ==== Camel case and underscore parameters deprecated in 6.x have been removed

docs/reference/migration/migrate_7_0/cluster.asciidoc

@@ -15,13 +15,18 @@ The default value for the `wait_for_active_shards` parameter of the open index A
 is changed from 0 to 1, which means that the command will now by default wait for all
 primary shards of the opened index to be allocated.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Shard preferences `_primary`, `_primary_first`, `_replica`, and `_replica_first` are removed
 These shard preferences are removed in favour of the `_prefer_nodes` and `_only_nodes` preferences.
+//end::notable-breaking-changes[]
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Cluster-wide shard soft limit
 Clusters now have soft limits on the total number of open shards in the cluster
 based on the number of nodes and the `cluster.max_shards_per_node` cluster
 setting, to prevent accidental operations that would destabilize the cluster.
-More information can be found in the <<misc-cluster,documentation for that setting>>.
+More information can be found in the
+{ref}/misc-cluster.html[documentation for that setting].
+//end::notable-breaking-changes[]

docs/reference/migration/migrate_7_0/discovery.asciidoc

@@ -2,19 +2,21 @@
 [[breaking_70_discovery_changes]]
 === Discovery changes
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Cluster bootstrapping is required if discovery is configured
 
 The first time a cluster is started, `cluster.initial_master_nodes` must be set
 to perform cluster bootstrapping. It should contain the names of the
 master-eligible nodes in the initial cluster and be defined on every
-master-eligible node in the cluster. See <<discovery-settings,the discovery
-settings summary>> for an example, and the
-<<modules-discovery-bootstrap-cluster,cluster bootstrapping reference
-documentation>> describes this setting in more detail.
+master-eligible node in the cluster. See
+{ref}/discovery-settings.html[the discovery settings summary] for an example, and the
+{ref}/modules-discovery-bootstrap-cluster.html[cluster bootstrapping reference
+documentation] describes this setting in more detail.
 
 The `discovery.zen.minimum_master_nodes` setting is permitted, but ignored, on
 7.x nodes.
+//end::notable-breaking-changes[]
 
 [float]
 ==== Removing master-eligible nodes sometimes requires voting exclusions
@@ -28,6 +30,7 @@ such as data-only nodes or coordinating-only nodes, voting exclusions are not
 required. Likewise, if you add nodes to the cluster, voting exclusions are not
 required.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Discovery configuration is required in production
 
@@ -44,6 +47,7 @@ file:
 The first three settings in this list are only available in versions 7.0 and
 above. If you are preparing to upgrade from an earlier version, you must set
 `discovery.zen.ping.unicast.hosts` or `discovery.zen.hosts_provider`.
+//end::notable-breaking-changes[]
 
 [float]
 ==== New name for `no_master_block` setting

docs/reference/migration/migrate_7_0/indices.asciidoc

@@ -2,10 +2,12 @@
 [[breaking_70_indices_changes]]
 === Indices changes
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Index creation no longer defaults to five shards
 Previous versions of Elasticsearch defaulted to creating five shards per index.
 Starting with 7.0.0, the default is now one shard per index.
+//end::notable-breaking-changes[]
 
 [float]
 ==== `:` is no longer allowed in index name

docs/reference/migration/migrate_7_0/java_time.asciidoc

@@ -1,6 +1,8 @@
+
+//tag::notable-breaking-changes[]
 [float]
 [[breaking_70_java_time_changes]]
-=== Replacing Joda-Time with java time
+==== Replacing Joda-Time with java time
 
 Since Java 8 there is a dedicated `java.time` package, which is superior to
 the Joda-Time library, that has been used so far in Elasticsearch. One of
@@ -10,6 +12,7 @@ to remove the Joda-Time dependency in the future.
 
 The mappings, aggregations and search code switched from Joda-Time to
 java time.
+//end::notable-breaking-changes[]
 
 [float]
 ==== Joda based date formatters are replaced with java ones

docs/reference/migration/migrate_7_0/mappings.asciidoc

@@ -14,12 +14,14 @@ This field used to index a composite key formed of the `_type` and the `_id`.
 Now that indices cannot have multiple types, this has been removed in favour
 of `_id`.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== The `_default_` mapping is no longer allowed
 
 The `_default_` mapping has been deprecated in 6.0 and is now no longer allowed
 in 7.0. Trying to configure a `_default_` mapping on 7.x indices will result in
 an error.
+//end::notable-breaking-changes[]
 
 [float]
 ==== `index_options` for numeric fields has been removed

docs/reference/migration/migrate_7_0/plugins.asciidoc

@@ -64,11 +64,13 @@ Setting.AffixSetting<String> MY_SETTING = Setting.affixKeySetting(
 
 The `RealmSettings.simpleString` method can be used as a convenience for the above.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== Tribe node removed
 
 Tribe node functionality has been removed in favor of
-<<modules-cross-cluster-search,Cross Cluster Search>>.
+{ref}/modules-cross-cluster-search.html[{ccs}].
+//end::notable-breaking-changes[]
 
 [float]
 ==== Discovery implementations are no longer pluggable

docs/reference/migration/migrate_7_0/search.asciidoc

@@ -205,6 +205,7 @@ on whether queries need to access score or not. As a result `bool` queries with
 `minimum_should_match` to 1. This behavior has been deprecated in the previous
 major version.
 
+//tag::notable-breaking-changes[]
 [float]
 ==== `hits.total` is now an object in the search response
 
@@ -232,6 +233,7 @@ You can also retrieve `hits.total` as a number in the rest response by adding
 `rest_total_hits_as_int=true` in the request parameter of the search request.
 This parameter has been added to ease the transition to the new format and
 will be removed in the next major version (8.0).
+//end::notable-breaking-changes[]
 
 [float]
 ==== `hits.total` is omitted in the response if `track_total_hits` is disabled (false)
@@ -241,6 +243,7 @@ will set `hits.total` to null and the object will not be displayed in the rest
 layer. You can add `rest_total_hits_as_int=true` in the search request parameters
 to get the old format back (`"total": -1`).
 
+//tag::notable-breaking-changes[]
 [float]
 ==== `track_total_hits` defaults to 10,000
 
@@ -271,3 +274,4 @@ documents. If the total number of hits that match the query is greater than this
 
 You can force the count to always be accurate by setting `"track_total_hits`
 to true explicitly in the search request.
+//end::notable-breaking-changes[]

docs/reference/migration/migrate_7_0/settings.asciidoc

@@ -2,12 +2,14 @@
 [[breaking_70_settings_changes]]
 === Settings changes
 
+//tag::notable-breaking-changes[]
 [float]
 ==== The default for `node.name` is now the hostname
 
 `node.name` now defaults to the hostname at the time when Elasticsearch
 is started. Previously the default node name was the first eight characters
 of the node id. It can still be configured explicitly in `elasticsearch.yml`.
+//end::notable-breaking-changes[]
 
 [float]
 ==== Percolator
@@ -94,6 +96,7 @@ default value of `false`.
 
 [float]
 [[include-realm-type-in-setting]]
+//tag::notable-breaking-changes-7.0
 ==== Security realms settings
 
 The settings for all security realms must now include the realm type as part
@@ -121,6 +124,7 @@ xpack.security.authc.realms:
 Any realm specific secure settings that have been stored in the elasticsearch
 keystore (such as ldap bind passwords, or passwords for ssl keys) must be updated
 in a similar way.
+//end::notable-breaking-changes-7.0
 
 [float]
 [[tls-setting-fallback]]
@@ -132,6 +136,7 @@ fallback to a default configuration when using TLS. Each component (realm, trans
 http client, etc) must now be configured with their own settings for TLS if it is being
 used.
 
+//tag::notable-breaking-changes[]
 [float]
 [[tls-v1-removed]]
 ==== TLS v1.0 disabled
@@ -144,6 +149,7 @@ You can enable TLS v1.0 by configuring the relevant `ssl.supported_protocols` se
 --------------------------------------------------
 xpack.security.http.ssl.supported_protocols: [ "TLSv1.3", "TLSv1.2", "TLSv1.1", "TLSv1" ]
 --------------------------------------------------
+//end::notable-breaking-changes[]
 
 [float]
 [[trial-explicit-security]]