Conditionally apply serialization on certain properties

Created by: Ghufz

ConditionalSerialization is exposed as flag when it sets to true it generates the shouldSerialize() method for each property along with flag which detect that property has been changes or set, if the property has been changed then the flag is set to true and ShouldSerialize return true, which allows the serialization that configured property in request body.

-This gives a control to the user to decide what are the properties can be set in request body irrespective of sending all the other property which user does not configured.

We face the issue mostly in the case of update the MO, where user wants to configure only one property but in the request all the nulllable properties set to null. which leads to inconsistency.

-This solved another use case where user is using the latest SDK which has newly added property to the existing object and the server side is not updated(working with older openAPIDoc). When user tries to send the request to the server the newly added property also become a part of request body which server does not know abut it, it leads to exception. ConditionalSerialization will not include those newly added property unless and until it is being configured by the user.

Here is the example :- Let say we have Name object which has two properties FirstName and LastName

when user wants to create new Name object the request would be like

{
     "FirstName": "Tom",
      "LastName" : "Harry"
}

once above object is created let say user wants to update only "LastName" so the payload as per the deafult Csharp SDK would be

{
  "FirstName" :  null,
  "LastName" :  "Xyz"
}

When the above request sents to the server, it updates the firstName as null along with LastName which leads to inconsistency. when we generate the C# SDK using the conditionalSerialization flag the above request cant be sent like below

{
     "LastName" : "Xyz"
}

the above request sends only those property which user has configured.

Note :- there is no change in default code generation.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh

  Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master, 5.1.x, 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. @wing328