feat: add opt-in toggle for managedFields inclusion in deserialization

[YuqiGuo105]

Summary

Since 22.0.0, V1MetadataExclusionStrategy has silently excluded managedFields from Gson (de)serialization by default to reduce noise. This broke users who rely on managedFields data and there was no supported way to re-enable them.

Closes #3995

---

Workflow: Before this fix

managedFields were silently dropped on every API response with no recourse:

// managedFields always empty, even when the server returns them
V1DeploymentList list = appsApi.listNamespacedDeployment(ns).execute();
List<V1ManagedFieldsEntry> fields =
    list.getItems().get(0).getMetadata().getManagedFields(); // []

The only workaround was reflection-based hacking into Gson's private factories field.

Workflow: After this fix

Call JSON.setIncludeManagedFields(true) once at startup to opt in. Everything else is unchanged:

// At application startup (once):
JSON.setIncludeManagedFields(true);

// Then use the API as normal — managedFields will be populated:
V1DeploymentList list = appsApi.listNamespacedDeployment(ns).execute();
List<V1ManagedFieldsEntry> fields =
    list.getItems().get(0).getMetadata().getManagedFields(); // [fleetagent, kubectl-rollout, ...]

To restore the default (exclude managedFields):

JSON.setIncludeManagedFields(false);

The default remains false (managedFields excluded) so all existing users are unaffected.

---

Changes

File	Change
V1MetadataExclusionStrategy.java	Add boolean includeManagedFields constructor param; when true, shouldSkipField() returns false immediately (no exclusion)
JSON.java	Add static includeManagedFields flag (default false); extract 700-line static {} into initGson() helper; add public static setIncludeManagedFields(boolean) that flips the flag and reinitialises the shared Gson instance
JSONTest.java	Three new tests: default exclusion, opt-in inclusion, and restoration of default after toggling
scripts/patches/json.diff	Updated patch so the changes survive future OpenAPI code regeneration

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: YuqiGuo105
Once this PR has been reviewed and has the lgtm label, please assign brendandburns for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: YuqiGuo105 / name: Yuqi Guo (642de36)

[k8s-ci-robot]

Welcome @YuqiGuo105!

It looks like this is your first PR to kubernetes-client/java 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-client/java has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-triage-robot]

Unknown CLA label state. Rechecking for CLA labels.

Send feedback to sig-contributor-experience at kubernetes/community.

/check-cla
/easycla

[brendandburns]

This file is auto generated from Kubernetes swagger, I think the fact that the field is missing means that the field must be missing from the swagger. We should fix that in the upstream swagger.

[YuqiGuo105]

This file is auto generated from Kubernetes swagger, I think the fact that the field is missing means that the field must be missing from the swagger. We should fix that in the upstream swagger.

Thanks for reviewing! I want to clarify the root cause — this is not a swagger / code generation issue.

The managedFields field is present in both the upstream swagger and the generated V1ObjectMeta.java (line 105). The server also returns the field in the HTTP response body (confirmed by the reporter in the linked issue).

The data is being silently dropped during Gson deserialization by V1MetadataExclusionStrategy — a hand-written (non-generated) class that tells Gson to skip the managedFields field on V1ObjectMeta. This strategy is injected into the generated JSON.java via json.diff after each code generation run.

This was an intentional change introduced in 22.0.0 with no public opt-out API, which is what broke the users in the linked issue. This PR adds a simple toggle (JSON.setIncludeManagedFields(true)) while keeping the default behavior unchanged.

[brendandburns]

I don't think this part of the change is necessary (the method refactor etc) please remove.

[brendandburns]

Rather than modifying this class, let's just not add the exclusion strategy if includeManagedFields is true in the JSON class below.