[Failure Store] Expose failure store lifecycle information via the GET data stream API

[gmarouli]

To retrieve the effective configuration you need to use the GET data streams API, for example, if a data stream has empty data stream options, it might still have failure store enabled from a cluster setting. The failure store is managed by default with a lifecycle with infinite (for now) retention, so the response will look like this:

GET _data_stream/*
{
  "data_streams": [
    {
      "name": "my-data-stream",
      "timestamp_field": {
        "name": "@timestamp"
      },
      .....
      "failure_store": {
        "enabled": true,
        "lifecycle": {
          "enabled": true
        },
        "rollover_on_write": false,
        "indices": [
           {
            "index_name": ".fs-my-data-stream-2099.03.08-000003",
            "index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
            "managed_by": "Data stream lifecycle"
          }
        ]
      }
    },...
]

In case there is a failure indexed managed by ILM the failure index info will be displayed as follows.

      {
          "index_name": ".fs-my-data-stream-2099.03.08-000002",
          "index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
          "prefer_ilm": true,
          "ilm_policy": "my-lifecycle-policy",
          "managed_by": "Index Lifecycle Management"
        }

[elasticsearchmachine]

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

[jbaiera]

LGTM, left a couple small comments. I think also now that we've removed the feature flag some of the code can be simplified.

[jbaiera]

Nit: It looks like this is only used in the rest action. Does it make sense to move this there? Alternatively, it's describing something about the structure of the response, should it be moved to the response object/action class?

[jbaiera]

Also, name wise, should we make this something like failure_store.lifecycle to denote specifically what part of the request is new? I see we have other changes to the response as well, so this is a soft suggestion. If you think this should be more generic to describe those changes that's also fine.