nftables mode for kube-proxy

Template:

Networking Definition of Planned

Epic Template descriptions and documentation 

Epic Goal

• Add an nftables mode to upstream kube-proxy

Why is this important?

• We want to move OpenShift Networking to make better use of upstream components, and having an nftables-based kube-proxy mode would let us migrate ovn-kubernetes to use it for Service proxying, without regressing on control plane performance like we would if we used iptables kube-proxy.
• We will likely have to support openshift-sdn for some customers on RHEL 10, but RHEL 10 will not support iptables.
• Though not important to OpenShift, it is important to Red Hat that there be a non-iptables-based kube-proxy mode upstream, since the iptables mode will no longer be usable in RHEL 10 (and some RHEL users run non-OpenShift Kubernetes).

Planning Done Checklist

The following items must be completed on the Epic prior to moving the Epic from Planning to the ToDo status

• Priority+ is set by engineering
• Epic must be Linked to a +Parent Feature
• Target version+ must be set
• Assignee+ must be set
• Enhancement Proposal is Implementable
• No outstanding questions about major work breakdown
• Are all Stakeholders known? Have they all been notified about this item?
• Does this epic affect SD? {}Have they been notified{+}? (View plan definition for current suggested assignee)

Additional information on each of the above items can be found here: Networking Definition of Planned

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement
  details and documents.

...

Dependencies (internal and external)

1.

...