Acquire read lock when marshalling container/task.

[fenxiong]

Summary

Acquire read lock when marshalling container/task. Without acquiring the lock the agent can crash due to concurrent access.

For example, when we are modifying the fields in container/task, there can be another goroutine invoking ForceSave to save the state, which calls the marshal method, and if the marshalling doesn't acquire the read lock, the program will crash even if the other goroutine acquires the write lock before modifying the field. See Testing section for an example.

Implementation details

Wraps container and task's MarshalJSON method with read lock.

Testing

For unit test, rely on existing statemanager unit test since this PR just adds the lock.

For manual test, this isn't easily reproducible, but it can be reproduced by intentionally invoking task.PopulateSecrets many times (see this) in the code, and run a task that uses secret, and without the fix the agent will crash like the following:

...
2019-12-02T22:01:58Z [INFO] Task engine [arn:aws:ecs:us-west-2:xxx:task/test-exec/xxx]: creating container: xxx
2019-12-02T22:01:58Z [INFO] Populate secrets 10000 times!
fatal error: concurrent map iteration and map write
...

I was able to verify that the issue is fixed with this commit.

Description for the changelog

Fixed a race condition that might cause the agent to crash during container creation.

Licensing

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

[fierlion]

looks good