[specific ci=1-14-Docker-Kill] publish containerPoweredOff event after kill

[chengwang86]

Fixes #5948

This PR should be able to at least alleviate the failure seen in our recent compost tests.

In the issue, when the VMPoweredOff event was to be processed, the container had already been removed from cache; therefore, we couldn't unbind the container from network. In this PR, we publish the containerPoweredOff event as soon as it is killed. This should guarantee that the container can be unbound from network most of the time. But it still does not fully resolve the race condition.

I think the race condition revealed by the compose test is quite general in our code and we need a comprehensive design for how to handle the async events, instead of changing our current logic for network rm and/or container rm as a fix.

[hmahmood]

Wouldn't this result in the powered off event getting published twice in some cases?

[chengwang86]

There are three places where this ContainerPoweredOff event is used:

1. https://github.com/vmware/vic/blob/master/lib/portlayer/network/network.go#L122
   If the container is already unbound by the previous ContainerPowerOff event, the second event would be a no-op.

2. https://github.com/vmware/vic/blob/master/lib/portlayer/exec/container.go#L647
   This should not make any difference.

3. https://github.com/vmware/vic/blob/master/lib/apiservers/engine/backends/eventmonitor.go#L230
   This would be a problem because docker event would show this event twice ... :(

[hmahmood]

Regardless of where the event is currently being consumed, this would potentially put any future uses of the event in jeopardy. It also is not correct to fire the event twice for the same occurrence. I would rather we not do this fix, especially since it also does not really address the problem.