[DOCS] Set explicit anchors in 6.8 for Asciidoctor (#42520)

docs/reference/how-to/indexing-speed.asciidoc

@@ -116,6 +116,7 @@ The default is `10%` which is often plenty: for example, if you give the JVM
 two shards that are heavily indexing.
 
 [float]
+[[_disable_literal__field_names_literal]]
 === Disable `_field_names`
 
 The <<mapping-field-names-field,`_field_names` field>> introduces some

docs/reference/migration/migrate_6_0/docs.asciidoc

@@ -7,6 +7,7 @@
 Document modification operations may no longer specify the `version_type` of
 `force` to override any previous version checks.
 
+[[_link_linkend_upserts_upserts_link_no_longer_support_versions]]
 ==== Upserts no longer support versions
 
 Adding a `version` to an upsert request is no longer supported.

docs/reference/migration/migrate_6_0/indices.asciidoc

@@ -39,6 +39,7 @@ following settings:
 - `index.shadow_replicas`
 - `node.add_lock_id_to_custom_path`
 
+[[_open_close_index_api_allows_wildcard_expressions_that_match_no_indices_by_default]]
 ==== Open/Close index API allows wildcard expressions that match no indices by default
 
 The default value of the `allow_no_indices` option for the Open/Close index API
@@ -64,6 +65,7 @@ The index parameter in the delete index API no longer accepts alias names.
 Instead, it accepts only index names (or wildcards which will expand to
 matching indices).
 
+[[_support_for_literal_literal_has_been_removed_in_index_expressions]]
 ==== Support for `+` has been removed in index expressions
 
 Omitting the `+` has the same effect as specifying it, hence support for `+`

docs/reference/migration/migrate_6_0/java.asciidoc

@@ -1,25 +1,29 @@
 [[breaking_60_java_changes]]
 === Java API changes
 
+[[_literal_setsource_literal_methods_require_xcontenttype]]
 ==== `setSource` methods require XContentType
 
 Previously the `setSource` methods and other methods that accepted byte/string representations of
 an object source did not require the XContentType to be specified. The auto-detection of the content
 type is no longer used, so these methods now require the XContentType as an additional argument when
 providing the source in bytes or as a string.
 
+[[_literal_deletebyqueryrequest_literal_requires_an_explicitly_set_query]]
 ==== `DeleteByQueryRequest` requires an explicitly set query
 
 In previous versions of Elasticsearch, delete by query requests without an explicit query
 were accepted, match_all was used as the default query and all documents were deleted
 as a result. From version 6.0.0, a `DeleteByQueryRequest` requires an explicit query be set.
 
+[[_literal_internalstats_literal_and_literal_stats_literal_getcountasstring_method_removed]]
 ==== `InternalStats` and `Stats` getCountAsString() method removed
 
 The `count` value in the stats aggregation represents a doc count that shouldn't require a formatted
 version. This method was deprecated in 5.4 in favour of just using
 `String.valueOf(getCount())` if needed
 
+[[_literal_actionrequestbuilder_execute_literal_returns_literal_actionfuture_literal_rather_than_literal_listenableactionfuture_literal]]
 ==== `ActionRequestBuilder#execute` returns `ActionFuture` rather than `ListenableActionFuture`
 
 When sending a request through the request builders e.g. client.prepareSearch().execute(), it used to
@@ -28,6 +32,7 @@ be possible to call `addListener` against the returned `ListenableActionFuture`.
 it is not possible to associate the future with listeners. The `execute` method that accept a listener
 as an argument can be used instead.
 
+[[_literal_terms_order_literal_and_literal_histogram_order_literal_classes_replace_by_literal_bucketorder_literal]]
 ==== `Terms.Order` and `Histogram.Order` classes replace by `BucketOrder`
 
 The `terms`, `histogram`, and `date_histogram` aggregation code has been refactored to use common
@@ -36,12 +41,14 @@ code for ordering buckets. The `BucketOrder` class must be used instead of `Term
 accessing internal order instances, e.g. `BucketOrder.count(boolean)` and `BucketOrder.aggregation(String, boolean)`.
 Use `BucketOrder.key(boolean)` to order the `terms` aggregation buckets by `_term`.
 
+[[_literal_gettookinmillis_literal_removed_in_literal_bulkresponse_literal_literal_searchresponse_literal_and_literal_termvectorsresponse_literal]]
 ==== `getTookInMillis()` removed in `BulkResponse`, `SearchResponse` and `TermVectorsResponse`
 
 In `BulkResponse`, `SearchResponse` and `TermVectorsResponse` `getTookInMiilis()` method
 has been removed in favor of `getTook` method. `getTookInMiilis()` is easily replaced by
 `getTook().getMillis()`.
 
+[[_literal_getfield_literal_and_literal_searchhitfield_literal_replaced_by_literal_documentfield_literal]]
 ==== `GetField` and `SearchHitField` replaced by `DocumentField`
 
 As `GetField` and `SearchHitField` have the same members, they have been unified into
@@ -57,6 +64,7 @@ The `org.elasticsearch.search.aggregations.bucket.terms.support` package was rem
 
 The filter aggregation classes were moved to `org.elasticsearch.search.aggregations.bucket.filter`
 
+[[_constructor_for_literal_percentileranksaggregationbuilder_literal_has_changed]]
 ==== Constructor for `PercentileRanksAggregationBuilder` has changed
 
 It is now required to include the desired ranks as a non-null, non-empty array of doubles to the builder's constructor,

docs/reference/migration/migrate_6_0/mappings.asciidoc

@@ -9,6 +9,7 @@ series the previous coercion rules will continue to work on pre-6.0 indices. Thi
 mappings immediately. However, it is not possible to create new indices from existing index templates that violate the strict `boolean`
 coercion rules.
 
+[[_the_literal__all_literal_meta_field_is_now_disabled_by_default]]
 ==== The `_all` meta field is now disabled by default
 
 On new mappings, the `_all` meta field that contains a copy of the text from
@@ -18,18 +19,21 @@ check if `_all` is enabled/disabled and switch to executing the query across all
 fields if `_all` is disabled. `_all` can no longer be configured for indices
 created with Elasticsearch version 6.0 or later.
 
+[[_the_literal_include_in_all_literal_mapping_parameter_is_now_disallowed]]
 ==== The `include_in_all` mapping parameter is now disallowed
 
 Since the ++_all++ field is now disabled by default and cannot be configured for
 indices created with Elasticsearch 6.0 or later, the `include_in_all` setting is
 now disallowed for these indices' mappings.
 
+[[_unrecognized_literal_match_mapping_type_literal_options_not_silently_ignored]]
 ==== Unrecognized `match_mapping_type` options not silently ignored
 
 Previously Elasticsearch would silently ignore any dynamic templates that
 included a `match_mapping_type` type that was unrecognized. An exception is now
 thrown on an unrecognized type.
 
+[[_validation_of_literal_locale_literal_on_date_fields]]
 ==== Validation of `locale` on date fields
 
 The `locale` option of `date` fields previously allowed almost any string values,

docs/reference/migration/migrate_6_0/packaging.asciidoc

@@ -10,6 +10,7 @@ possible, the DEB and RPM packages now exclusively use the user and group
 should use the tarball distribution instead of the provided RPM and DEB
 packages.
 
+[[_literal_path_conf_literal_is_no_longer_a_configurable_setting]]
 ==== `path.conf` is no longer a configurable setting
 
 Previous versions of Elasticsearch enabled setting `path.conf` as a
@@ -19,6 +20,7 @@ Elasticsearch should use another config file. Instead, to configure a custom
 config directory, use the <<config-files-location,`ES_PATH_CONF` environment
 variable>>.
 
+[[_literal_conf_dir_literal_is_no_longer_supported]]
 ==== `CONF_DIR` is no longer supported
 
 Previous versions of Elasticsearch enabled using the `CONF_DIR` environment
@@ -61,6 +63,7 @@ We previously attempted to ensure that Elasticsearch could be started on 32-bit
 JVM (although a bootstrap check prevented using a 32-bit JVM in production). We
 are no longer maintaining this attempt.
 
+[[_literal_server_literal_flag_no_longer_filtered_in_the_windows_service]]
 ==== `-server` flag no longer filtered in the Windows service
 
 Related to the previous change that 32-bit is no longer supported, the default
@@ -72,6 +75,7 @@ flag was removed from the installation of the Windows service. This means that
 if you have a `jvm.options` file that includes this flag you will need to remove
 it.
 
+[[_literal_es_jvm_options_literal_is_no_longer_supported]]
 ==== `ES_JVM_OPTIONS` is no longer supported
 
 The environment variable `ES_JVM_OPTIONS` that enabled a custom location for the
@@ -80,6 +84,7 @@ The environment variable `ES_JVM_OPTIONS` that enabled a custom location for the
 support relocating the configuration files so this change merely aligns the
 other configuration files with the location of the `jvm.options` file.
 
+[[_literal_es_include_literal_is_no_longer_supported]]
 ==== `ES_INCLUDE` is no longer supported
 
 The environment variable `ES_INCLUDE` could previously be used to establish the

docs/reference/migration/migrate_6_0/plugins.asciidoc

@@ -83,6 +83,7 @@ Indices created in the previous major version will need to be reindexed
 in order to return correct (and correctly ordered) results,
 and to take advantage of new characters.
 
+[[_plugins_should_not_construct_literal_environment_literal_instances_from_literal_settings_literal]]
 ==== Plugins should not construct `Environment` instances from `Settings`
 
 Previously, plugins could construct an `Environment` instance from `Settings` to

docs/reference/migration/migrate_6_0/reindex.asciidoc

@@ -1,6 +1,7 @@
 [[breaking_60_reindex_changes]]
 === Reindex changes
 
+[[_literal_size_literal_parameter]]
 ==== `size` parameter
 
 The `size` parameter can no longer be explicitly set to `-1`. If all documents are required then the `size` parameter should not be set.

docs/reference/migration/migrate_6_0/rest.asciidoc

@@ -38,6 +38,7 @@ In previous versions of Elasticsearch, Analyze API is requiring a `tokenizer` or
 In Elasticsearch 6.0.0, Analyze API can analyze a text as a keyword field with custom normalizer
 or if `char_filter`/`filter` is set and `tokenizer`/`analyzer` is not set.
 
+[[_literal_timestamp_literal_and_literal_ttl_literal_in_index_requests]]
 ==== `timestamp` and `ttl` in index requests
 
 `timestamp` and `ttl` are not accepted anymore as parameters of index/update
@@ -103,6 +104,7 @@ $ curl -v -XPOST 'localhost:9200/my_index/_settings'
 * Connection #0 to host localhost left intact
 -------------------------------------------
 
+[[_disallow_using_literal__cache_literal_and_literal__cache_key_literal]]
 ==== Disallow using `_cache` and `_cache_key`
 
 The `_cache` and `_cache_key` options in queries have been deprecated since version 2.0.0 and

docs/reference/migration/migrate_6_0/scripting.asciidoc

@@ -23,6 +23,7 @@ milliseconds since epoch as a `long`. The same is true for
 `doc.some_date_field[some_number]`. Use `doc.some_date_field.value.millis` to
 fetch the milliseconds since epoch if you need it.
 
+[[_removed_access_to_index_internal_via_the_literal__index_literal_variable]]
 ==== Removed access to index internal via the `_index` variable
 
 The `_index` variable has been removed. If you used it for advanced scoring, consider writing a `Similarity` plugin.
@@ -32,6 +33,7 @@ The `_index` variable has been removed. If you used it for advanced scoring, con
 All of the existing scripting security settings have been removed.  Instead
 they are replaced with `script.allowed_types` and `script.allowed_contexts`.
 
+[[_literal_lang_literal_can_no_longer_be_specified_when_using_a_stored_script_as_part_of_a_request]]
 ==== `lang` can no longer be specified when using a stored script as part of a request
 
 The `lang` variable can no longer be specified as part of a request that uses a stored

docs/reference/migration/migrate_6_0/search.asciidoc

@@ -137,6 +137,7 @@ produces. BM25 is recommended instead.
 See https://issues.apache.org/jira/browse/LUCENE-7347[`LUCENE-7347`] for more
 information.
 
+[[_fielddata_on_literal__uid_literal]]
 ==== Fielddata on `_uid`
 
 Fielddata on `_uid` is deprecated. It is possible to switch to `_id` instead
@@ -156,15 +157,18 @@ The `postings` highlighter has been removed from Lucene and Elasticsearch.
 The `unified` highlighter outputs the same highlighting when `index_options` is set
  to `offsets`.
 
+[[_literal_fielddata_fields_literal]]
 ==== `fielddata_fields`
 
 The deprecated `fielddata_fields` have now been removed. `docvalue_fields` should be used instead.
 
+[[_literal_docvalue_fields_literal]]
 ==== `docvalue_fields`
 
 `docvalue_fields` now have a default upper limit of 100 fields that can be requested.
 This limit can be overridden by using the `index.max_docvalue_fields_search` index setting.
 
+[[_literal_script_fields_litera]]
 ==== `script_fields`
 
 `script_fields` now have a default upper limit of 32 script fields that can be requested.
@@ -180,6 +184,7 @@ In prior versions the source field names were relative to the inner hit.
 The `from` parameter can no longer be used in the search request body when initiating a scroll.
 The parameter was already ignored in these situations, now in addition an error is thrown.
 
+[[_limit_on_from_size_in_top_hits_and_inner_hits]]
 ==== Limit on from/size in top hits and inner hits
 
 The maximum number of results (`from` + `size`) that is allowed to be retrieved

docs/reference/migration/migrate_6_0/stats.asciidoc

@@ -1,6 +1,7 @@
 [[breaking_60_stats_changes]]
 === Stats and info changes
 
+[[_removal_of_literal_throttle_time_literal_in_the_literal_store_literal_stats]]
 ==== Removal of `throttle_time` in the `store` stats
 
 Given that store throttling has been removed, the `store` stats do not report