Add frozen phase to ILM UI

[cjcenizal]

Previously implemented in #75968 and then removed in #77877

API

Per @dakrone, the frozen phase API is stable enough to develop a UI against, with code merged into master that supports:

• The data_frozen frozen tier node role (Add the frozen tier node role and ILM phase elasticsearch#68605)
• Frozen phase in ILM policies
• Partial searchable snapshot support in ILM (Add support for partial searchable snapshots to ILM  elasticsearch#68714)

The available actions in the frozen phase are:

• set priority
• unfollow
• allocate
• freeze
• searchable snapshot

UX considerations

All searchable snapshot actions must use the same repository

Support for different repositories is not going to be in 7.12 and is unlikely to ever be implemented since it seems like a corner case. ILM will reject a policy if you have multiple searchable snapshot actions specifying different repos (elastic/elasticsearch#68856).

A naive UX solution to this constraint would be to surface validation errors if the user selects different repositories for multiple searchable snapshot actions.

A more sophisticated solution would be to prompt the user to specify a single policy-wide repository that will apply to all searchable snapshot actions. But this introduces its own challenges -- where would we surface this input? How do we maintain the connection to the searchable snapshot actions that it configures?

The searchable snapshot storage option is optional

If the storage option of the searchable_snapshot action isn't configured, it will default to different values depending on the phase it's in:

• In the hot and cold phases it will default to a full searchable snapshot.
• In the frozen phase it will default to a partial searchable snapshot.

Full searchable snapshots store primary data locally and store replica data in the snapshot. Primary data is restored from the snapshot if it's lost.

Partial searchable snapshots store no data locally. When the index is queried, they transfer data from the snapshot as it's needed, with some additional local caching.

Lee's guidance is that the UI doesn't need to provide a value for this option unless the user wants to.

The searchable snapshot action precludes some subsequent actions

Once searchable snapshot is enabled, certain other actions are disallowed from executing afterwards. This list was pulled from the ES code:

• shrink
• force merge
• freeze
• rollup

Note: The ES code lists searchable snapshot as also disallowed but elastic/elasticsearch#68864 has been opened to allow it.

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[dakrone]

specify a single policy-wide repository that will apply to all searchable snapshot actions. But this introduces its own challenges -- where would we surface this input? How do we maintain the connection to the searchable snapshot actions that it configures?

This is related to our idea of adding support for a default repository elastic/elasticsearch#66040

[cjcenizal]

@sebelga Could you please review the Cloud UX of this functionality with @zanbel at some point?

[sebelga]

@cjcenizal of course, we'll do a full UX test on Cloud. 👍

[cjcenizal]

Thanks @sebelga. Recently we've been investing in improving the Cloud-specific UX (for example #90592 and #90894), so I was thinking it would be good to chat with Roy earlier in the process and verify any Cloud-specific requirements to consider before getting too far along into implementation.

[cjcenizal]

Addressed by #93068