Update usage constraints of Data Access Control

[ledoug]

What does this PR do? What is the motivation?

Updates Data Access Control documentation in preparation for GA. These updates:

• Reflect which telemetry types are part of GA vs still in preview
• Clarifies updated interaction between Logs RBAC and DAC
• Adds usage constraint for Monitors not being subject to DAC restrictions
• Updated RUM constraints -- Session Replay sub-features do not get turned off now unless RUM is in a dataset

Merge instructions

Merge readiness:

• [ X] Ready for merge

[github-actions]

Preview links (active after the build_preview check completes)

Modified Files

• https://docs-staging.datadoghq.com/doug.benedicto/data-access-control-constraints/account_management/rbac/data_access

[ledoug]

@amyli-dd and @abe-lin-dd to review as well

[abe-lin-dd]

Should we just remove this?

Extended Retention does not work with Data Access Control because the data store that holds the extended data does not support access restrictions.

[amyli-dd]

+1, best not to delve into implementation details imo

[ledoug]

Updated

[amyli-dd]

Maybe something like "This gap will be addressed in a future iteration." ?

[ledoug]

Updated

[joepeeples]

Opened DOCS-12727 to assign a Docs writer and follow up with editorial review.

[urseberry]

Suggested change

	- Software Delivery repository info (CI Visibility pipelines)
	- Software Delivery repository info (in CI Visibility pipelines)

[urseberry]

Suggested change

	Data Access Control is separate from the existing [Logs RBAC permissions][11] feature, also known as log restriction queries. We recommend using a single solution to restrict logs data, but user access be limited by restrictions applied from either system.
	Data Access Control is separate from the existing [Logs RBAC permissions][11] feature, also known as log restriction queries. Datadog recommends using a single solution to restrict logs data. If you limit user access using both Data Access Control and log restriction queries, both sets of restrictions apply.

[urseberry]

Suggested change

	Users can create Monitors that query and alert on active telemetry. While the user will only be able to directly query data they’re allowed to access, the Monitor will operate as a System User with full access to data. This gap will be addressed in a future iteration. We encourage customers who are concerned about this to carefully monitor which Monitors are created by their users and restrict the ability to create these Monitors.
	Users can create monitors that query and alert on active telemetry. While the user can only directly query data they're allowed to access, the monitor operates as a system user with full access to data.
	If you are concerned about unauthorized data access through monitors, Datadog recommends that you track the monitors your users create. Then, restrict access to the creation of monitors that read sensitive data.

I had to remove the line about a future iteration because the public docs are timeless, and only describe the current state. They don't make promises about the future.