[feature request] Allow the users to do the serialization by their own for the payload in Direct Methods

[brycewang-microsoft]

This is from the issue #1584 where we notice there might be different behaviors across different JSON serialization and deserialization libraries when sending and receiving the direct method payloads. For instance, using Gson in Java and NewtonSoft in .NET. Therefore, it would be great to allow the users to do the serialization by their own, rather than giving the full control to the SDK internally.

[BenD10]

Prior to SDK v2, we used Jackson for serialization of payloads in direct method responses, but now with the SDK upgrade we were forced to switch to Gson, including updating a bunch of Jackson annotations to Gson in order to control field names.

This would be a very welcome addition!

[The-Funk]

+1 for this request. I typically use Jackson for serialization, full manual serialization would be nice but I know device twins have specific formatting requirements.

Just a quick example, I'd like the ability to configure a Jackson object mapper to write datetimes as longs representing milliseconds since epoch. This is very easy with Jackson. Rather than writing the conversion code for that to get an object that the IoT SDK could then serialize, I could just serialize my data with my Jackson objectmapper prior to adding it to the patch document,

Maybe the TwinCollection class could have a method putPrepared(String propID, String serializedValue)?

Alternatively if the SDK could partially expose the GSON mapper that it uses internally, I imagine this could be easily doable in that manner as well.

[ranjith-t]

For me gson looks to be a good option especially with class object serialization. I would be happy to have additional options available to user based on their preference rather than removing it completely.