[Alerting] Simplify RBAC to remove complicated "Role visibility" situation

[jasonrhodes]

This is a placeholder ticket to reference our ongoing need to work with ResponseOps to remove and/or improve the complicated "role visibility" concept that dictates how some observability rules specify role-based access control for the rule instance and its associated alerts.

Currently, the custom threshold rule and the ES query rule both ask users to select a value from a dropdown called "role visibility" which usually contains some or all of the following options:

• Logs
• Metrics
• Stack Alerts

Once this has been selected and the rule created, this is not an editable value after that point. What it does is dictate which Kibana feature is required for viewing/editing the created rule instance, as well as for viewing/interacting with the associated alerts that may be triggered by this rule instance. For example, if you create a custom threshold rule and give it a "role visibility" value of "Logs", only users with the "Logs > Read" feature enabled for their Kibana user role will be able to see that this rule and its alerts exist, and only users with the "Logs > Admin" feature enabled for their Kibana user role will be able to edit this rule.

For users who want to interact with "Observability" as a unified whole, this selection is confusing at best and nonsensical at worst. We should do some combination of the following:

• Hide this value completely from the user and choose the value that makes sense on their behalf
• Allow a selection of "observability" which acts as an "OR" on the various Kibana features that can grant access to this
• Rename the concept to something that makes more intuitive sense
• Consider whether this should be an editable value after creation
• Think through any other possible consequences of the existing situation

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)