decoupling unmatched handling from kubernetesdeserializer

[shawkins]

Description

As either a stand alone change or part of one of the other serialization issues #3972 or #4024 I'd like to remove the coupling between the KubernetesDeserializer and the unmatched property handling. This change elevates that to the Serialization level. This will further allow us to change the handling of parsing / processing parameters - that has been embedded down in the serialization layer as raw string processing, but it doesn't need to be. Parsing with unmatched type handling on, or parsing as a map would allow for post processing of property substitution.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

67.6% Coverage
0.0% Duplication

[shawkins]

@manusa marking as a WIP, since we probably won't make it far with cleaning up the static nature of KubernetesDeserializer, it isn't imperative to make this change just yet.

[manusa]

Does #4171 address the issues that this PR tries to fix?
(I feel really uncomfortable extending the ObjectMapper.)

[shawkins]

Does #4171 address the issues that this PR tries to fix?

No, this pr is more general. It would have addressed #4171 as well as the ability to do something like client.templates().list() - when you have non-string parameters (currently that will throw a parsing exception), and eventually fully decouple the template processing from parsing (that currently requires simple string substitution prior to parsing).

[shawkins]

Replaced by #4109