Onu adapter reconcilement may stuck on VLAN processing, especially in TT traffic scenarios

In TT traffic scenario three rules are configured that are applied to the VLAN config FSM and which must be 'reactivated' during reconcilement after some adapter restart.
At flow reconcilement the VLAN FSM gets processing request to configure these three flows.
Depending on internal timing such subsequent configuration may fall into a time slice where the FSM has already detected that all requested flows have been configured. Based on asynchronous event reception the FSM then starts a new (pro-forma) configuration round ending up in the same successful check again (so far no issue). It then tries to send a a new channel indication to signal that the reconcilement has finished, but this repeated sending has no receiver anymore and thererfore blocks. At that time now the semaphore mutexFlowParams is locked, thus preventing nearly all further relevant VLAN config FSM activities.
The problem was detected based on robot failed tests detecting that after device delete there where still some ONU resources available in the KvStore (etcd). This is caused indirectly by a prior VLAN config FSM blocking as the internally called resetFsm() function now also blocks on the cancel VLAN config FSM processing. This way resources are never correctly released in such case.
Observed e.g. here: https://jenkins.opencord.org/view/All%20Jobs/job/periodic-voltha-openonu-go-test-bbsim/695/artifact/reconcile-openonu-go-adapter-test-tt/