OpenOnuAdapter Techprofile configuration/removal deadlock when conflicting with ONU down handling

There is a deadlock situation when a just started TechProfile configuration/removal actions is directly followed by some ON down event handling.

Such can sporadically be observed in the Multi-ONU processing of the soft-reboot test case handling. Here the processing request reception for the GemPort removal and the ONU down indication might fall into such critical sequence that leads to this effect.

Internally the ONU down indication yields the call of resetFsm() that should stop all the FSM processing and also some ongoing techProfile configuration. But the implementation runs onto a mutex deadlock preventing the resetFsms() function and the GemPortRemoval processing to complete.

As a result of this behavior subsequent system requests are not correctly received/processed anymore for this device and the device stays in some previously set state (rebooting in this specific situation).