[ProtocolTests] query sub object serialization refactor

[SergeyRyabinin]

Issue #, if available:
Protocol tests implementation
Description of changes:
Refactor query sub-object serialization to avoid template duplication

It generates an ugly diff on base64 blob serialization, but it is expected:

• base64 may contain + and / characters;
• these characters are reserved per rfc3986 and must be %-encoded. This was done for few cases originally of base64-encodind, but not all, and since this PR unifies how elements are serialized - this effect occurs.

Also it generates an ugly diff on enum serialization, the issue is the same: sometimes we were rfc-encoding enums, sometimes not. While service model owners might be responsible for having their enums rfc-compliant, it is a safer bet for SDK to be compliant and consistent on enum encoding.

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]

looks like the smithy refactor rollback had unintended consequences here. how should the "protocol clients" handle this migrations/should they?

[SergeyRyabinin]

I'd say it was a miss when we did the revert.
Once tests are stable - they will be added to a regular regeneration and build-execution list.

[sbera87]

Does it handle nested structures?
Meaning if A has B has C has D, will it appropriately generate the accessor location?

[sbera87]

One generic comment I have is to consider as food for thought if it's better to generate different classes following appropriate design pattern to handle 'ec2' vs rest cases. The different classes would come from smaller template files for ec2 vs rest cases. This can help maintainability (due to less branching in code) and readability.