Allow external controller to deploy ksvc using SSA

[pastequo]

This issue was originally reported in slack (https://cloud-native.slack.com/archives/C04LMU0AX60/p1705591161751469) and knative serving & networking meeting.

This issue should be fixed when the pod go struct will have the right annotations. (https://kubernetes.slack.com/archives/C0123CNN8F3/p1705594643726679) Those annotations are currently on k8s main branch but not in any release yet (at the time of the writing)

• Main: https://github.com/kubernetes/api/blob/master/core/v1/types.go#L3549-L3550 (present)
• v0.29.1: https://github.com/kubernetes/api/blob/v0.29.1/core/v1/types.go#L3501 (missing)
• v0.30.0-alpha0: https://github.com/kubernetes/api/blob/v0.30.0-alpha.0/core/v1/types.go#L3501 (missing)

kube PR: https://github.com/kubernetes/kubernetes/pull/121759

In what area(s)?

/area API /kind spec

What version of Knative?

Probably all

0.9.x 0.10.x 0.11.x

Expected Behavior

While creating a knative service resource using SSA (server side apply), the different apply that contains the same knative spec shouldn't change the object & should not trigger additional reconciliation loop.

More specifically, knative serving mutating webhook should patch independently the field it cares about.

Actual Behavior

While creating a knative service resource using SSA (server side apply), the spec is modified by the knative serving mutating webhook. Those modifications change the resourceVersion and trigger indefinitely the reconciliation loop.

The granularity of the managedField is not fine enough, which is probably causing the endless loop

Steps to Reproduce the Problem

N.A

[dprotaso]

/triage accepted

[dprotaso]

Upstream changes won't land till k8s/1.30 - in the meantime we can test changes by manually manipulating our CRD open api scheme to see if they work