Antrea-native policies: Update podSelector semantics in ACNP

[abhiraut]

Describe what you are trying to solve
Users want to reduce the management overhead of security policies by writing succinct Antrea-native policies. For example, a namespace isolation policy for the entire cluster (inter-ns deny, intra-ns allow), currently users must create a default-allow policy per Namespace instead of a single Cluster scoped policy. This is due to the fact that the ACNP is not expressive enough to satisfy the above use case.

Describe the solution you have in mind
ACNP podSelector today selects Pods from all Namespaces. This semantics is rather redundant because the same can be achieved by including an empty NamespaceSelector in the peer with PodSelector like

{
  PodSelector: some-labelSelector,
  NamespaceSelector: {}
}

This leaves us with a choice to update the semantics of PodSelector without any NamespaceSelector to a different meaning, one which is similar to how they are evaluated in K8s NetworkPolicies.
For example, a PodSelector by itself in a To/From rule should now select Pods from the same Namespace as that of the Pod in appliedTo.

Old semantics:

PodSelector: Select Pods from all Namespaces and rules apply to/from Pods from all Namespaces.

New semantics:

PodSelector: Select Pods from all Namespaces but rules apply to/from Pods within the appliedTo Pods own Namespace.

In order to achieve the older semantics using new semantics, each ACNP's ingress/egress rule podSelector peer must be accompanied with an empty namespaceSelector.

eg.

ingress:
  - from:
    - podSelector:      // Selects app:client Pods from appliedTo Pod's own Namespace.
        matchLabels:
          app: client

can be transformed to a new policy and maintaining the old semantics as :

ingress:
  - from:
    - podSelector:      // Selects app:client Pods from Namespaces selected by namespaceSelector, since it is empty, it selects from all Namespaces.
        matchLabels:
          app: client
      namespaceSelector: {}

Using the new semantics, one can easily write a single Namespace isolation ACNP as follows:

apiVersion: "security.antrea.tanzu.vmware.com/v1alpha2"
kind: ClusterNetworkPolicy
metadata:
    name: ns-isol
spec:
    appliedTo:
    - namespaceSelector:    {}          // Select all Namespaces
    ingress:       
    - from:                             // Allow ingress traffic from all Pods from AppliedTo Pod's own Namespace
      action: Allow
      - podSelector:        {}
    - from:                             // Deny ingress traffic from all Pods from all Namespaces.
      action: Deny
      - podSelector:        {}
        namespaceSelector:  {}

Since the allow rule allows intra-namespace traffic and comes before the deny rule to deny all ingress traffic, the intra-namespace traffic will be allowed and any other traffic will be dropped by the deny rule.

Describe how your solution impacts user flows
The ACNP apiVersion will be bumped up to v1alpha2 and older policies will be internally converted to this new semantics by automatically populating the empty namespaceSelector. Users must now be informed of the new semantics and start using v1alpha2 version of the policies.

Describe the main design/architecture of your solution
A clear and concise description of what does your solution look like. Rich text and diagrams are preferred.

Alternative solutions that you considered
A list of the alternative solutions that you considered, and why they fell short. You can list the pros and cons of each solution.

Test plan
In addition to e2e and unit tests, upgrade tests must be added to ensure smooth upgrade workflows.

[Dyanngg]

superseded by #1941