Send optional fields as nil instead of "" to ECS

[hencrice]

Previously when sending certain requests that contain optional fields to ECS through the Go AWS SDK, we always send empty strings instead of nil for those optional fields that are not set. The service treats such an action as an explicit intent and hence fails to plug in the default values from the service side.

This PR closes #927. Specifically, the repo 3.

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing

• Unit tests passed
• Integration tests passed
• [N/A] Unit tests added for new functionality
• Listed manual checks and their outputs in the comments (example)
  I was able to run ecs-cli compose service up instead of getting the named volume [backup-laptop] is used but no declaration was found in the volumes section error message described in the issue. Also verified the default, "local" driver, was correctly set on the service side in task def:

"volumes": [
    {
      "name": "backup-laptop",
      "host": null,
      "dockerVolumeConfiguration": {
        "autoprovision": false,
        "labels": null,
        "scope": "shared",
        "driver": "local",
        "driverOpts": null
      }
    }
  ]

• [N/A] Link to issue or PR for the integration tests:

Documentation

• [N/A] Contacted our doc writer
• [N/A] Updated our README

---

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

[sonofachamp]

Can we use omitempty yaml struct tags on the fields?

omitempty - Only include the field if it's not set to the zero
value for the type or to empty slices or maps.
Zero valued structs will be omitted if all their public
fields are zero, unless they implement an IsZero
method (see the IsZeroer interface type), in which
case the field will be included if that method returns true.

[kohidave]

Is there any way folks may have come to depend on this empty string behavior? I guess what I'm asking is if we launch this, are a bunch of folks going to see resources being created or destroyed and be surprised?

[hencrice]

Can we use omitempty yaml struct tags on the fields?

omitempty - Only include the field if it's not set to the zero
value for the type or to empty slices or maps.
Zero valued structs will be omitted if all their public
fields are zero, unless they implement an IsZero
method (see the IsZeroer interface type), in which
case the field will be included if that method returns true.

I'm afraid omitempty is only applicable during the Marshal function provided by the yaml package. Since we are simply doing in-memory transformation, adding that tag does not seem to help.

[hencrice]

Is there any way folks may have come to depend on this empty string behavior? I guess what I'm asking is if we launch this, are a bunch of folks going to see resources being created or destroyed and be surprised?

1. For those customers who already provide non-empty strings for these fields, they will be ok.
2. For the others who have been providing empty strings, they would not have successfully registered their task definitions (same as repo3 in errors with managed docker volume plugins with ecs-cli compose service up #927 ). I'm leaning toward fixing this because I think it's a bug that prevents the legitimate use case which relies on the defaults provided by the service. This change will only impact those customers who explicitly rely on the 400 user error and in that worst case, resources will be created instead of destroyed.