[Reporting] upgrade notes for Reporting feature privilege breaking ch…

…anges (elastic#207897)

## Summary

Breaking change proposal: elastic/dev#2556

This PR updates the upgrade note documentation to explain the 9.0.0
changes around Reporting access control

docs/upgrade-notes.asciidoc

@@ -249,6 +249,28 @@ Upgrade to use the Risk Engine in all spaces which use the legacy risk scoring m
 - If the original user and host risk score modules are enabled, you'll see a button to "Start update". Click the button, and follow the instructions.
 ====
 
+[discrete]
+[[breaking-200834]]
+.Reporting uses Kibana feature privileges only to control access to reporting features
+[%collapsible]
+====
+*Details* +
+--
+In 8.x, the default access control model was based on a built-in role called `reporting_user`, which granted access to reporting features. Since 7.13, the preferred model for controlling access to reporting features has been Kibana feature privileges, enabled by setting `xpack.reporting.roles.enabled: false` in `kibana.yml`.
+
+In 9.0.0, the `xpack.reporting.roles.*` settings will be ignored.
+--
+
+*Impact* +
+The built-in `reporting_user` role is no longer deprecated and provides access to reporting features using Kibana feature privileges. This means that users that do not have privileges to use reporting will not see reporting features in the Kibana UI.
+
+*Action* +
+Use Kibana feature privileges to control access to reporting features. For more information, see {kibana-pull}200834[#200834].
+
+- The `reporting_user` role is still supported, but gives full access to all reporting features. We recommend creating custom roles with minimal privileges in **Stack Management > Roles**.
+- The `xpack.reporting.roles.allow` setting is no longer supported. If you have a `xpack.reporting.roles.allow` value in your `kibana.yml`, you should remove this setting and assign privileges to reporting features using Kibana feature privileges.
+====
+
 [float]
 === Deprecation notices