Default field manager is different if Jetty is used compared to other HTTP Clients

[csviri]

Describe the bug

When jetty is used the default fieldManager will be "Jetty" while in other cases it will be "fabric8-kubernetes-client".

Fabric8 Kubernetes Client version

SNAPSHOT

Steps to reproduce

in Java Operator SDK this test would fail if there is no exception made for jetty:

https://github.com/java-operator-sdk/java-operator-sdk/blob/5acd152303b35921f2c863583f5b863a5a41de33/operator-framework/src/test/java/io/javaoperatorsdk/operator/DependentSSAMigrationIT.java#L82-L82

See also the IT failaing here:
https://github.com/java-operator-sdk/java-operator-sdk/actions/runs/5219232210/jobs/9420832654

Expected behavior

Have the fieldManager consistently same for all clients: fabric8-kubernetes-client.

Runtime

minikube

Kubernetes API Server version

1.25.3@latest

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[shawkins]

Kubernetes must be inferring the default fieldManager from the User-Agent. This implies the HeaderInterceptor is effectively not working against Jetty.

For server side apply we instead use just fabric8 as the default fieldManager - that seems to be working as expected since it's in the url correct?