This is a clone of BZ https://bugzilla.redhat.com/show_bug.cgi?id=2117374 which fixed 4.12

 
Description of problem:
OCP 4.11 introduced the `restricted-v2` SecurityContextConstraint as the default binding for all authenticated users. When a Pod that would have normally be admitted successfully using the `restricted` SCC, but cannot be admitted using a `restricted-v2` SCC, it's not clear to the customer that the problem is related to the default SCC changing from restricted to restricted-v2.

Suggestion is to generate an additional message for this specific use case that makes it clear to customers that they have a workload that is not compatible with restricted-v2.

Example message:
Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: the pod fails to validate against the default `restricted-v2` security context constraint, but would validate successfully against the `restricted` security context constraint.

The goal of such a message is to give the customer a breadcrumb that the `restricted-v2` SCC is activated and set as the default, which they may have not been aware of. This would give them a way to find alternatives, such as changing the global default, fixing the application or assigning the `restricted` SCC to the Namespace or ServiceAccount.

Version-Release number of selected component (if applicable):
4.11

How reproducible:
Always

Steps to Reproduce:
1. Install OCP 4.11.0
2. Create a deployment with a podtemplate with .spec.containers[*].securityContext.allowPrivigeEscalation = true in a new namespace

Actual results:
The pod will fail to be admitted with an error such as:

Warning FailedCreate 27m (x25 over 76m) replicaset-controller Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: unable to validate against any security context constraint: [provider "anyuid": Forbidden: not usable by user or serviceaccount, spec.containers[0].securityContext.allowPrivilegeEscalation: Invalid value: true: Allowing privilege escalation for containers is not allowed, provider "restricted": Forbidden: not usable by user or serviceaccount, provider "nonroot-v2": Forbidden: not usable by user or serviceaccount, provider "nonroot": Forbidden: not usable by user or serviceaccount, provider "noobaa": Forbidden: not usable by user or serviceaccount, provider "noobaa-endpoint": Forbidden: not usable by user or serviceaccount, provider "hostmount-anyuid": Forbidden: not usable by user or serviceaccount, provider "machine-api-termination-handler": Forbidden: not usable by user or serviceaccount, provider "hostnetwork-v2": Forbidden: not usable by user or serviceaccount, provider "hostnetwork": Forbidden: not usable by user or serviceaccount, provider "hostaccess": Forbidden: not usable by user or serviceaccount, provider "rook-ceph": Forbidden: not usable by user or serviceaccount, provider "node-exporter": Forbidden: not usable by user or serviceaccount, provider "rook-ceph-csi": Forbidden: not usable by user or serviceaccount, provider "privileged": Forbidden: not usable by user or serviceaccount]

Expected results:
Add an additional or replacement error message when there is no SCC assignment other than `restricted-v2` AND `restricted` would have worked:

Error creating: pods "nginx-ingress-controller-75bffcfdf8-" is forbidden: the pod fails to validate against the default `restricted-v2` security context constraint, but would validate successfully against the `restricted` security context constraint.

Additional info: