DEVEXP-:254 support undefined vs null detection for serialization

[JPPortier]

Java Optional do not enable to detect if a value was explicitly set with a null value or not explicitly` for requests.
So SDK was not able to reset by using the specific null value onto payloads

Adding OptionalValue class having same logic as native Optional but:

• enabling to set null as an expected value (for native java Optional it is specific value)
• internal state store information enabling to known if value was explicitly set
• when converted to DTO: only set values for explicitly initialized values from business logic layer

Then:

• generated DTO are extended to have knowledge about fields set (internal field xxxDefined and associated getter getXXXDefined)
• onto serialization: If explicitly set: serialize the value (null or not)

So final payload can:

• send 'null' value to reset a field
• do not send the field identifier if not explicitly requested to

Benefits:

• enable to distinct fields for edition (setting a value vs resetting when sent with null or not sent)
• reduce request payload received by servers
• business logic related to required field is delegated to shared mapper and based onto DTO description generated from OAS file (com.sinch.sdk.core.utils.databind.Mapper)

Main points:

• new class: OptionalValue: https://github.com/sinch/sinch-sdk-java/blob/DEVEXP-254-support-undefined-vs-null-detection-for-serialization/core/src/main/com/sinch/sdk/core/models/OptionalValue.java
• Jakson filter to manage if field is having to be serialize (was explicitly set) or not: https://github.com/sinch/sinch-sdk-java/blob/DEVEXP-254-support-undefined-vs-null-detection-for-serialization/core/src/main/com/sinch/sdk/core/utils/databind/Mapper.java#L43

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues found.

Scanned Manifest Files

[Dovchik]

The PR is massive, I've reviewed key points which looks good.