Changing back TaskProtectionResponse to use pointers for nested struct fields

[mye956]

Summary

This PR will change back the TaskProtectionResponse struct to have pointers to its struct fields (e.g. ProtectionTask and Failure) so that the response body will respect the omitempty.

Implementation details

• Changed back types.* to *types.* for the struct fields of TaskProtectionResponse

Testing

• Modified the unit tests to also test that the response JSON string is what we intend it to be
• Manual testing

Before this change:

root@e71d43e2b5e5:/# curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
{"protection":{"ExpirationDate":null,"ProtectionEnabled":false,"TaskArn":"arn:aws:ecs:us-west-2:*:task/963adc2fcf1d4095bff50879c2840d01"},"failure":{"Arn":null,"Detail":null,"Reason":null}}

After:

root@c811d7572190:/# curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
{"protection":{"ExpirationDate":null,"ProtectionEnabled":false,"TaskArn":"arn:aws:ecs:us-west-2:*:task/b513ca611b3f48efabc0d753978ed91a"}}

New tests cover the changes: yes

Description for the changelog

Bugfix - Change back to having struct field pointers within TaskProtectionResponse

Additional Information

Does this PR include breaking model changes? If so, Have you added transformation functions?

Does this PR include the addition of new environment variables in the README?

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[willmyrs]

Would it be possible for this to be three different structs? It seems that Protection, Failure, and RequestID+Error should never be in the same response, based on the public documentation. Just a thought; I see that the tests now enforce this, which is sufficient.

[ShelbyZ]

Do we have or need a test that covers the omitempty for Failures?

[mye956]

Do we have or need a test that covers the omitempty for Failures?

I think the happy case scenario cover this.