CoreV1Api#deleteNamespacedService expect wrong response object type

[tipame]

Describe the bug
APIdeleteNamespacedServiceRequest#execute returns V1Service.
Actually server response with V1Status (in terms of lib api).
So client response handler code fails on parsing Status json to V1Service dto:

java.lang.IllegalArgumentException: The field `details` in the JSON string is not defined in the `V1Service` properties. JSON: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Success","details":{"name":"dummy","kind":"services","uid":"7839a223-28f5-495a-a4af-838ca25a4489"}}
	at io.kubernetes.client.openapi.models.V1Service.validateJsonElement(V1Service.java:262)
	at io.kubernetes.client.openapi.models.V1Service$CustomTypeAdapterFactory$1.read(V1Service.java:307)
	at io.kubernetes.client.openapi.models.V1Service$CustomTypeAdapterFactory$1.read(V1Service.java:297)
	at com.google.gson.TypeAdapter$NullSafeTypeAdapter.read(TypeAdapter.java:314)
	at com.google.gson.Gson.fromJson(Gson.java:1361)
	at com.google.gson.Gson.fromJson(Gson.java:1262)
	at com.google.gson.Gson.fromJson(Gson.java:1171)
	at com.google.gson.Gson.fromJson(Gson.java:1137)
	at io.kubernetes.client.openapi.JSON.deserialize(JSON.java:799)
	at io.kubernetes.client.openapi.ApiClient.deserialize(ApiClient.java:909)
	at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:1119)
	at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:1043)
	at io.kubernetes.client.openapi.apis.CoreV1Api.deleteNamespacedServiceWithHttpInfo(CoreV1Api.java:22126)
	at io.kubernetes.client.openapi.apis.CoreV1Api$APIdeleteNamespacedServiceRequest.execute(CoreV1Api.java:22253)

Client Version
23.0.0 | 22.0.1

Kubernetes Version
v1.21.14

Java Version
Java 17

To Reproduce

CoreV1Api api = new CoreV1Api(apiClient);
api.deleteNamespacedService(name, namespace).execute();

Expected behavior
Expect V1Status as a return type for service delete request.

[brendandburns]

The issue here is that that method returns either V1Status or a V1Namespace depending on whether it is actually deleted quickly or not.

We hacked around this with the old client generator, but I think that in moving to the new generator, the hack/fix to make this work got broken.

We'll need to see if there's a good way to fix this in the new client generator.

[brendandburns]

cc @yue9944882

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten