…s-in-all-the-places

* elastic/master: (70 commits)
  Remove experimental label froms script_score query (elastic#41572)
  [Ml-Dataframe] Update URLs in Data frame client java doc (elastic#41539)
  Reenable bwc Tests in master (elastic#41540)
  Fix search_as_you_type's sub-fields to pick their names from the full path of the root field (elastic#41541)
  Remove search analyzers from DocumentFieldMappers (elastic#41484)
  Update community client and integration docs (elastic#41513)
  Remove Version.V_6_x_x constants use in security (elastic#41185)
  Mute testDriverConfigurationWithSSLInURL
  Remove dedicated SSL network write buffer (elastic#41283)
  Disable max score optimization for queries with unbounded max scores (elastic#41361)
  [DOCS] Explicitly set section IDs for Asciidoctor migration (elastic#41547)
  [ML] add multi node integ tests for data frames (elastic#41508)
  [Docs] Fix common word repetitions (elastic#39703)
  [DOCS] Note TESTRESPONSE can't be used immediately after TESTSETUP (elastic#41542)
  Update configuring-ldap-realm.asciidoc (elastic#40427)
  Fixed very small typo in date (elastic#41398)
  Refactor GeoHashUtils (elastic#40869)
  Make 0 as invalid value for `min_children` in `has_child` query (elastic#41347)
  field_caps: adapt bwc version after backport (elastic#41427)
  Remove Exists Check from S3 Repository Deletes (elastic#40931)
  ...

This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC testing code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: elastic#41164

This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC testing code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.

Relates: elastic#41164

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in elastic#41185 along
with tests.

Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in #41185 along
with tests.

…2221)

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in elastic#41185 along
with tests.

…92295)

Officially Elasticsearch is compatible with last major at data level.
Therefore v8 is not compatible with v6. However we don't have a guided
migration path for stored authentication headers, e.g. upgrade assistant
does not do anything for them. Therefore it is more helpful and user
friendly for v8 to support v6 stored authentication headers.

This PR adds back the version conditional logic removed in #41185 along
with tests.

…2274)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

…astic#92274)

Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

…2274) (#92318)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of elastic#92274

Due to elastic#41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to elastic#87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of elastic#92274

…em (#92323)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of #92274

…em (#92324)

Due to #41185 datafeeds created prior to 7.0 and not updated since
then have unparseable authorization headers in 8.x. In 8.0-8.3 this
could easily be a non-issue, as such datafeeds were likely forgotten
leftovers and never run. Even if it was a problem, only the datafeed
of interest would need updating with any urgency.

Due to #87884 datafeeds with authorization headers older than 7.0
prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn
breaks the anomaly detection job management section of the ML UI.

The problem is alleviated by #92168 and fixed by #92221, but we
should warn users that the problem exists in 8.4.0-8.5.3 inclusive.

Backport of #92274