bugfix: fix lock competition between Stats and Start interface

[HusterWan]

Signed-off-by: Michael Wan [email protected]

Ⅰ. Describe what this PR did

We use Stats interface to get running container's resource metrics, and this api can be called at any time of the container's life cycle.

If we called the Stats interface when the container is starting, there may caused Stats or Start failed because of lock competition.

The code that get the lock:

     if !c.lock.Trylock(id) {
          return nil, errtypes.ErrLockfailed
       }
       defer c.lock.Unlock(id)
  

The log that get lock failed:

time="2018-09-12T16:57:10.49956582+08:00" level=error msg="failed to decode metrics of container "b36804c94a701cfb5f8e3c27c6e9eed096e8179f6352ec465df156efb01b28c8": failed to get stats of container "b36804c94a701cfb5f8e3c27c6e9eed096e8179
f6352ec465df156efb01b28c8": lock failed"

500 Internal Server Error: {"message":"failed to create container(${CNRID}) on containerd: lock failed"}

So, in order to avoid the lock competition, we should just get the Metrics just when the container is running

Ⅱ. Does this pull request fix one issue?

none

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)

This situation is very hard to write test case.

Ⅳ. Describe how to verify it

none

Ⅴ. Special notes for reviews

none

[fuweid]

return nil will panic if the StreamStat toContainerStats consumes the result.

[HusterWan]

make sense, i have fix it.

[fuweid]

LGTM