Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 4:

 - Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes

 - Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs 

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

1. - [ ] Mandatory Add the required version to the Fix version/s field. 2.11.0

2. - [x] Mandatory Choose the type of documentation change.

      - [ ] New topic in an existing section or new section
      - [x] Update to an existing topic

3. - [x] Mandatory for GA content:
            
       - [x] Add steps and/or other important conceptual information here: 
         In the tech preview release in 2.10, we required users to specify `spec.subscription.installPlanApproval` in the OperatorPolicy. In the GA release in 2.11, setting this field is invalid (the policy will not do anything, except report an error describing that setting this field is invalid). Instead, the user must set `spec.upgradeApproval`. We believe this field is more clear than the `installPlanApproval` setting which was based on the field in the OLM Subscription type, but which the operator policy controller would have to override in many situations, making it potentially confusing.
            
       - [x] Add Required access level for the user to complete the task here:
       policy admin 

       - [x] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     this is not a task
     
       - [x] Add link to dev story here: https://issues.redhat.com/browse/ACM-11268

4. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation:

Current doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html-single/governance/index#policy-operator or in github: https://github.com/stolostron/rhacm-docs/blob/2.11_stage/governance/policy_operator.adoc 

Remove the (Technology Preview) note from the title - this will be a generally available feature.

Add a note to the `spec.subscription` row that setting `installPlanApproval` will cause the policy to be invalid.

Replace the `subscriptions.installPlanApproval` row in the table with `spec.upgradeApproval`. It is (still) Required. Description: If the `upgradeApproval` field is set to `Automatic`, the policy will approve upgrades on the cluster to versions allowed by the policy, when the policy is being enforced. If the field is set to `None`, it will not approve any upgrades to the specified operator. Note that regardless of this setting, the initial installation of the operator will be approved (if it is an allowed version) if the policy is being enforced.

Current doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html-single/governance/index#install-operator-with-policy or on github: https://github.com/stolostron/rhacm-docs/blob/2.11_stage/governance/install_operator.adoc#install-operator-with-policy 

Remove the (Technology Preview) note from the title - this will be a generally available feature.

Remove the `installPlanApproval` line in the example yaml. Set `spec.upgradeApproval` to "Automatic" instead.

(Note that the two fields are at different indentation levels)

New section? Maybe in "What's new" for this release?

If you have been using OperatorPolicy while it is in Technology Preview, there are some changes you will need to make to your policies. The `installPlanApproval` field should no longer be set under `spec.subscription`. Instead, `spec.upgradeApproval` is now required to be either "Automatic" or "None", and provides more clear control of which InstallPlans will be approved. Until this change is made to the policies, they will be NonCompliant, and not perform any enforcement actions on the cluster.