Granting kibana_system reserved role access to "all" privileges to .internal.preview.alerts* index

[dplumlee]

Required for: elastic/kibana#116374

Summary
An extension of #76624 and #80746. Adding for the new rule preview feature that utilizes alerts as data and a reserved index for kibana_system user to read/write alerts. We are writing to a separate internal index than normal alerts so they won't show up with standard .internal.alerts* queries, but still need the same permissions as "normal" alert indices

[elasticmachine]

Pinging @elastic/es-security (Team:Security)

[ywangd]

LGTM

I am not very familiar with the alerts as data work. So this might not be the right question. But why do we have to prepend different strings to the .alerts namespace? We already granted Kibana all access to .alerts*, which seems to be a viable top-level namespace for covering all usages required by alerts-as-data? That is, is it more organised and easier if we use suffix instead of prefix for sub namespaces? i.e. instead of .internal.alerts*, .preview.alerts* and .internal.preview.alerts*, we replace them with .alerts.internal.*, .alerts.preview.*, .alerts.internal_preview.*?

[dplumlee]

@ywangd The way the new alerts as data feature is set up, it was intentional to separate the fields from the general .alerts* namespace as you mentioned. However, I definitely agree that it's something we should revisit later, this is just the consensus that the RAC team came to for the time being. Whether it be separating the fields using datasets or some other naming convention I think there's some room for improvement with fewer index permissions needed

[elasticsearchmachine]

💚 Backport successful

[marshallmain]

This appears not to have made it back to 8.0 and is required for #81379. Is there a backport script we can run to easily backport it?