…ts testUpdates elastic#137512

…fls (elastic#137442)

…astic#137023)

Following elastic#136813, we expose to data stream lifecycle the new sampling method config in the downsampling API. This will allow users to configure the sampling method directly in the lifecycle configuration. For example:
```
PUT _data_stream/my-ds/_lifecycle
{
  "data_retention": "10d",
  "downsampling_method": "last_value",
  "downsampling": [
     {
       "after": "1d",
       "fixed_interval": "5m
     }
  ]
}
```

As of elastic#133954, we clone indices before performing the force-merge step in the `searchable_snapshot` action. On slow CI servers, 10 seconds for the index to go through the whole `searchable_snapshot` action isn't enough, so we bump the timeout to 20 seconds.

I looked at the logs of a few test failures, and ILM was clearly still progressing when the test timed out. I didn't identify any particular step that was taking extraordinarily long; there were always just a few steps that took a bit longer. I would love to make these tests faster rather than bumping the timeout, but the `searchable_snapshot` action is simply one of the largest ILM actions and ILM itself isn't particularly fast.

That being said, if a timeout of 20 seconds proves to be insufficient (i.e. test failures come back), I do think it's worth having a look at reducing the runtime of the tests somehow first before we increase the timeout further.

Closes elastic#137149
Closes elastic#137151
Closes elastic#137152
Closes elastic#137153
Closes elastic#137156
Closes elastic#137166
Closes elastic#137167
Closes elastic#137192

…elastic#137520)

This reverts commit 4d3e27f. And then
re-applies the revert to
elastic#134738, so we only get an
effective revert of 
elastic#134511.

…37510)

When Dataframes are disabled, do not try to call the Action and instead
assume there are no trained models associated with a dataframe job. This
avoids a transport exception for the disabled action.

…LMIntegration {targetCluster=FOLLOWER} elastic#137494

…hRollover {targetCluster=FOLLOWER} elastic#137528

This adds a new abstract method to MapperTestCase for checking whether
a particular field type configuration supports competitive iterators during
sorting.

…hat it was resolved to (elastic#136632)

* alexey-ivanov-es work

* iter

* field caps: local resolution working and tested

* CCS impl

* using CPS SAF resolution if present

* some TODOs to check later on

* [CI] Update transport version definitions

* iter

* iter

* iter

* iter

* Update docs/changelog/136632.yaml

* [CI] Auto commit changes from spotless

* iter

* iter

* iter

* iter

* only return resolved to if minTransportVersion supports it

* iter

* updated comment based on feedback

---------

Co-authored-by: elasticsearchmachine <[email protected]>

…lastic#137404)

In elastic#137139, ES819DocValuesFormat version will increment from 0 to 1. For bwc tests between version 0 and version 1, we need a copy of version 0. So copy the existing ES819TSDBDocValuesConsumer to ES819TSDBDocValuesConsumerVersion0 and add TestES819TSDBDocValuesFormatVersion0 which uses this consumer. Since ES819TSDBDocValuesConsumer and ES819TSDBDocValuesConsumerVersion0 are currently identical, this does not test anything yet, but will once elastic#137139 increments the version.

…ic#137459)

Mainly this is about removing the trappy implicit default master node
timeout in resize (shrink/split/clone) requests as per elastic#107984, but also
we drop the unnecessary `ActionType` subclass and the test-only
`ResizeRequestBuilder`, migrating the affected tests over to a new
`ResizeIndexTestUtils` instead. We also fix the order of index-name
arguments and make the `ResizeType` a mandatory parameter rather than
(trappily) defaulting to `SHRINK`.