Description:

Goal Summary:

Allow PAC users to choose a strict behavior for PaC which prevents policy changes from being made outside of their gitops control.  

Goals and expected user outcomes:

Anti Drift Option: As an ACS admin, I need a way to ensure that we do not introduce drift from the UI. I would like the following functionality:

1. I want an option to prevent UI users from making changes to PaC policies, so that I can guarantee that we have no drift in the system.  I would have preferred that this option be per cluster, but I will accept a solution where this setting is global.
2. I want to turn this option on/off in the UI and in the API as a privileged and audited action
3. When the option is on, UI users who try to modify an externally managed policy will get an explanation why this action is blocked and how unblocking can be controlled by the administrator
4. When the option is on, UI users will be able to create custom policies that will be marked as internally managed  but not to activate them. This allows users to benefit from the visual editor and "save as CRD" without creating drift
5. Upon attempt to turn the option on, the system will validate that no internally managed policy is active. If that is not the case, the attempt will fail , and the system will list all the offending policies. In the UI, it would be nice to have a bulk option to simplify deactivation. For example if I can select items from the list to be deactivated, and/or if each line item links to the policy definition editing screen where I can do this myself. 
6. Upon attempt to turn the option on, the system will WARN if any system policies are activate and recommend that they be deactivated and list them.  This action will succeed even if the warnings are not handled.
   In the UI it would be nice to have some bulk actions:
   1. a similar way to deactivate them as for internally managed policies
   2. an easy way to "clone and disable"  selected  policies which will produce the YAML CR for the selected policies and disable them.

Acceptance Criteria:

A list of specific needs or objectives that a feature must deliver in order
to be considered complete. Be sure to include nonfunctional requirements
such as security, reliability, performance, maintainability, scalability,
usability, etc. Initial completion during Refinement status.

<enter general Feature acceptance here>

Success Criteria or KPIs measured:

A list of specific, measurable criteria that will be used to determine if
the feature is successful. Include key performance indicators (KPIs) or
other metrics., etc. Initial completion during Refinement status.

<enter success criteria and/or KPIs here>