After a channel's applier that worked in MTS mode has stopped due to
an error, an expected slave worker recovery routine is ineffective.
There will be no attempt to fix gaps in transaction execution left by
the stopped session.
That can lead to repeated applying of some other
transactions with all sort of idemponent (and not only) errors when
MTS slave restarts and turns to execution of GAPs transaction left
out at the last run.

MTS initialization is refined to get it back effective even if there're
multiple channels configured. For that the replication info repository
access methods are modified to make use of PK info that identify Worker
records accross channels too.