PoC - [Failure store]: prework to facilitate failure lifecycle.

[gmarouli]

In this PR we perform some pre-work to facilitate the introduction of the failure lifecycle. The goal of this PR prepare our code base to start using the failure store lifecycle configuration as soon as it becomes available.

Extracting basic lifecycle behaviour in an interface
We extract an interface called BasicDataSteamLifecycle which is meant to abstract the basic behaviour we expect every lifecycle to have. Meaning:

1. To be enabled or disabled.
2. To have a retention.
3. To be able to calculate the effective retention.

The current DataStreamLifecycle implements this interface and extends the provided functionality by adding the downsampling feature too.

In a follow up PR, the FailureStoreLifecycle will also extend it. This split is necessary for now, because we want to follow the new templating framework we introduced with #117357. When we move the data stream lifecycle also under the data_stream_options we can reevaluate if the interface makes sense.

Separate functionally data and failure lifecycle

In the DataStream we split the lifecycle to two, the data and failure lifecycle. Currently, they refer to the exact same configuration but this will change in the follow up PR.

Open tasks:

• See how it works with ExplainIndexDataStreamLifecycle

Update: Re-evaluating earlier than expected because I am wondering if this is causing issues when serialising it in ExplainIndexDataStreamLifecycle.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[gmarouli]

Having two configuration classes will not work nicely with the lifecycle explain code. For this reason, we abort this PR.