[ProtocolTests] Refactor XML serialization codegen template,

[SergeyRyabinin]

Also fixes fixes wrong timestamp format in a corner case

Issue #, if available:
Protocol tests
Description of changes:
Refactor how XML serialization logic is generated by creating macro functions that can generate a corresponding code, instead of repeating the logic in the every case.
Check all that applies:

• Did a review by yourself.
• Added proper tests to cover this PR. (If tests are not applicable, explain.)
• Checked if this PR is a breaking (APIs have been changed) change.
• Checked if this PR will not introduce cross-platform inconsistent behavior.
• Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

• Linux
• Windows
• Android
• MacOS
• IOS
• Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sbiscigl]

${timestamptFormatStr} this might be a missing code gen case

[sbiscigl]

should cmake be changing in this revision? some seem to be getting -namespace others removing -namespace anything up there?

[SergeyRyabinin]

It is the issue of the code gen not being stable. Will fix soon.

[sbera87]

if possible can it be simplified into
userMetadataMapEntryNode.CreateChildElement("key").SetText(mapItem.first)
and
userMetadataMapEntryNode.CreateChildElement("value").SetText(mapItem.first)
from the codegen?
i.e. can we support chaining for the setters at a node level for all its immediate children?

[sbera87]

One way I have dealt with this in the past is from java (using recursive function and a context) to generate the code and then just use the code in the template. This will greatly simplify the velocity template and push the computation on the Java side

[sbera87]

for reference for idea:

aws-sdk-cpp/tools/code-generation/generator/src/main/java/com/amazonaws/util/awsclientgenerator/transform/OperationContextCppCodeGenerator.java

Line 9 in 1a48e8b

public final class OperationContextCppCodeGenerator{

[SergeyRyabinin]

Both key and value types can be other than Strings,

please refer to a generated example:

   XmlNode intEnumMapParentNode = parentNode.CreateChildElement("intEnumMap");
   for(const auto& mapItem : m_intEnumMap)
   {
     XmlNode intEnumMapMapEntryNode = intEnumMapParentNode.CreateChildElement("entry");
     XmlNode intEnumMapKeyNode = intEnumMapMapEntryNode.CreateChildElement("key");
     intEnumMapKeyNode.SetText(mapItem.first);
     XmlNode intEnumMapValueNode = intEnumMapMapEntryNode.CreateChildElement("value");
     ss << mapItem.second;
     intEnumMapValueNode.SetText(ss.str());
     ss.str("");
   }

the current approach is to create a parent element following the model, then create key/value elements following the same model.
The macro serializing the each individual element does not care about if we are within Map or List, it just knows the current item to be serialized under the current parent.
Trying to optimize the appearance of generated code will make the codegen even harder.

Move to generating the code to .java is also quite debatable.
It may appear to be easier on a first glance, but on a fresh look, the complexity looks equal. The .vm allows to match the generated output to the template, while the simple streaming of new code into the buffer using any programming language does not.

The current goal is to make SDK compliant with protocol tests.
Refactoring and optimizations of generated models will follow later.

[sbera87]

lgtm. left ideas for later optimizaton