Refactor PUT DLM lifecycle API parsing

[nielsbauman]

We currently parse the request body of the PUT _data_stream/{name}/_lifecycle API in pretty much the same way as we parse DataStreamLifecycle objects. We currently already use the latter in the data stream options API.

By reusing that parser in this API too, we can remove some code and we'll automatically be able to parse new fields in this API when they get added to DataStreamLifecycle in the future. If there ever comes a point where there's a discrepancy between the two, we can always go back to having separate parsers.

[elasticsearchmachine]

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

[masseyke]

This seems like a really good change to me. Tagging @gmarouli in case she knows of some reason we intentionally didn't do this in the first place.

[gmarouli]

I think it should work now. We used to have different parsers because in the the DataStreamLifecycle was accepting explicit null. Then we split it into two parsers the direct configuration and the template configuration. I believe it should work now.

[nielsbauman]

Thanks for having a look, @gmarouli!

I indeed noticed that the parser in the API doesn't allow explicit null values. Is there a reason why we did that? By not allowing null values, we are preventing users from removing the retention and downsampling component. With this change, users will be able to remove those components. Is there a reason we didn't allow that before?

[gmarouli]

Is there a reason why we did that?

Explicit null values are not recommended in the api of elasticsearch, the absence of a value is enough to unset it. This is exactly how this API works as well, for example the following will unset the downsampling as you are mentioning:

{
   "data_retention": "3d"
}

The explicit null value has significance only in template composition, because we merge the component templates we do not override them. It is an exception to the general recommendation because it has different semantics.

[nielsbauman]

Ahh right, I missed that somehow. Thanks for the explanation @gmarouli!