Avoid sending a signal to the containers during checkpointing

### Description

In some scenarios, there are cases where the checkpoint time is very long, exceeding 30 seconds, and possibly even longer. During the checkpoint process, the mutex kernel.extMu is already locked. At this point, if the runsc list command is executed, it will hang because the container.SignalContainer function will attempt to acquire the kernel.extMu mutex. This can lead to a blockage. I believe this blockage situation is inappropriate; it would be better not to send signals to containers that are currently undergoing checkpointing.

### Is this feature related to a specific bug?

This is not related to a specific bug

### Do you have a specific solution in mind?

I think it would be better to add a flag to avoid sending signals to containers that are currently checkpointing, but I haven't come up with a good solution for it.