[ProtocolTests] #1 Protocol tests generation stub and cmake

[SergeyRyabinin]

Issue #, if available:
Protocol tests
Description of changes:
Adds generation of stubs (empty dummy projects) for protocol tests.
Also, generates the cmake script and wires them to a corresponding test client.
Build of protocol tests can be enabled in cmake by adding -DENABLE_PROTOCOL_TESTS=ON (OFF by default).
However, if attempted to build tests, the build fail because of some issues that these tests uncover, I will cover actual tests generation and build issues fixes in the following PRs.

Tested by re-generating all and building.

The generated tests will look like:

generated/protocol-tests/tests
├── input
│   ├── ec2
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   ├── json
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   ├── json_1_0
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   ├── query
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   ├── rest-json
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   ├── rest-xml
│   │   ├── CMakeLists.txt
│   │   └── RunTests.cpp
│   └── rest-xml-1
│       ├── CMakeLists.txt
│       └── RunTests.cpp
└── output
    ├── ec2
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    ├── json
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    ├── json_1_0
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    ├── query
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    ├── rest-json
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    ├── rest-xml
    │   ├── CMakeLists.txt
    │   └── RunTests.cpp
    └── rest-xml-1
        ├── CMakeLists.txt
        └── RunTests.cpp

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]

nit: could be static class i believe

[sbiscigl]

nit: use stack int instead of heap Integer since we're not making a collection

[sbiscigl]

do we actually need JsonNodeDeserializer and a type adapter registered? this pattern is kind of weird. we use a jackson type adapter in gson. we should really only be using one or the other. is there any reason we actually need this type adapter? from what i can tell we dont do any special serialization we just call object mapper, so I'm pretty sure we dont actually need this adapter to exist.

[SergeyRyabinin]

in protocol tests, there is a test suite definition, with a pre-defined schema which is known and can be coded into a known object model tree.
However, the input/output parameters definition is not known and evaluated only during runtime:

https://github.com/aws/aws-sdk-cpp/blob/main/tools/code-generation/protocol-tests/output/json_1_0.json#L882-L888
The tests are design to hold an arbitrary json, such as:

                "result": {
                    "stringValue": "string",
                    "documentValue": [
                        true,
                        false
                    ]
                },

and it will be different per each test/operation.
My plan is to not parse this structure into an object tree, but evaluate during the runtime of test generation.

I've chosen JsonNode because I've already used it on a similar project.
Essentially, I need just some duck-typed dict() class here, and JsonNode would suite it.
Also, having gson to parse the known Json structure and Jackson JsonNode is a kind of mental distinguishing exercise here.

[sbiscigl]

doesnt seem like we use this import

[SergeyRyabinin]

we actually use

velocityEngine.addProperty(RuntimeConstants.RUNTIME_LOG_INSTANCE, new NOPLoggerFactory().getLogger(""));

[sbiscigl]

you should be using the try with resources pattern here i.e.

try(final StringWriter sw = new StringWriter();) {
    //...do stuff with sw
}

[sbera87]

lgtm