fix(kube-ovn): raise ovs-ovn CPU limit/request to relieve ovn-controller throttling (#3050)

## What this PR does

**Problem.** `ovn-controller` runs inside the `ovs-ovn` DaemonSet's
single `openvswitch` container, sharing one CPU limit with
`ovsdb-server` and `ovs-vswitchd`. The container CPU limit was `2` cores
and the request `10m`. For three latency-sensitive daemons on a busy
cluster that ceiling is tight: under a burst of pod creation (a large
install with many concurrent HelmReleases) `ovn-controller` is CPU-bound
while programming OpenFlow for newly created logical ports, and a `10m`
request leaves it almost no guaranteed share under node CPU contention.

**Change.** Raise the `ovs-ovn` container CPU limit from `2` to `4`
cores and the request from `10m` to `100m`, so the co-located daemons
have headroom under burst and `ovn-controller` keeps a guaranteed
scheduling share under contention. Memory is unchanged — the change is
scoped to CPU.

**Scope — hardening, not a proven fix.** This change started from a
hypothesis that CPU throttling was lengthening flow-programming and
causing transient host→pod unreachability (`connection refused` from a
pod's own node) during burst installs. A live trace of a captured
occurrence of that symptom showed **zero** `ovs-ovn` CPU throttling in
the failure window, so the throttle ceiling was **not** the cause of
that failure. This PR therefore lands as a cheap, safe, well-bounded
headroom improvement on a ceiling that is genuinely tight for three
co-located daemons — not as a fix for the unreachability flake, whose
root cause is separate and still open.

**Test.** `helm template` confirms the rendered `ovs-ovn` DaemonSet now
sets `requests.cpu: 100m` and `limits.cpu: 4` (with `ephemeral-storage:
1Gi` inherited from the subchart default). A new helm-unittest
regression guard pins the raised limit and request.

### Screenshots

No UI changes.

### Release note

```release-note
fix(kube-ovn): raise the ovs-ovn container CPU limit to 4 cores (request to 100m) so the co-located ovn-controller/ovsdb-server/ovs-vswitchd daemons have CPU headroom under burst installs
```

packages/system/kubeovn/Makefile

@@ -4,6 +4,9 @@ export NAMESPACE=cozy-$(NAME)
 include ../../../hack/common-envs.mk
 include ../../../hack/package.mk
 
+test:
+	helm unittest .
+
 update:
 	rm -rf charts values.yaml Chart.yaml
 	tag=$$(git ls-remote --tags --sort="v:refname" https://github.com/cozystack/kubeovn-chart | awk -F'[/^]' 'END{print $$3}') && \

packages/system/kubeovn/tests/ovs-ovn-resources_test.yaml

@@ -0,0 +1,37 @@
+suite: ovs-ovn container CPU resources
+
+# Pins the CPU headroom this package gives the ovs-ovn DaemonSet container.
+# ovn-controller runs inside that one container (alongside ovsdb-server and
+# ovs-vswitchd) and is CPU-bound while programming OpenFlow for newly created
+# logical ports; under a burst install it CFS-throttles against the container
+# CPU limit, lengthening flow-programming lag. The limit must stay at 4 cores
+# (not the upstream/legacy 2) and the request must keep a guaranteed share so
+# the controller keeps up under contention.
+
+templates:
+  - charts/kube-ovn/templates/ovsovn-ds.yaml
+
+release:
+  name: kubeovn
+  namespace: cozy-kubeovn
+
+tests:
+  - it: ovs-ovn container carries the raised CPU limit and a guaranteed request
+    asserts:
+      - isKind:
+          of: DaemonSet
+      - equal:
+          path: spec.template.spec.containers[0].name
+          value: openvswitch
+      - equal:
+          path: spec.template.spec.containers[0].resources.limits.cpu
+          value: 4
+      - equal:
+          path: spec.template.spec.containers[0].resources.requests.cpu
+          value: 100m
+
+  - it: ovs-ovn CPU limit is not the throttle-prone 2 cores
+    asserts:
+      - notEqual:
+          path: spec.template.spec.containers[0].resources.limits.cpu
+          value: 2

packages/system/kubeovn/values.yaml

@@ -25,11 +25,18 @@ kube-ovn:
       cpu: "3"
       memory: "4Gi"
   ovs-ovn:
+    # ovn-controller runs inside this container (alongside ovsdb-server and
+    # ovs-vswitchd) and is CPU-bound while programming OpenFlow for newly
+    # created logical ports. During a burst install (many pods created at
+    # once) it competes for CPU in this one container; too tight a limit makes
+    # it CFS-throttle, lengthening flow-programming lag that leaves fresh pods
+    # unreachable from their node until the flows land. Give it CPU headroom
+    # (limit) plus a guaranteed share (request) so it keeps up under burst.
     requests:
-      cpu: "10m"
+      cpu: "100m"
       memory: "50Mi"
     limits:
-      cpu: "2"
+      cpu: "4"
       memory: "1000Mi"
   kube-ovn-controller:
     requests: