Unexpected behavior of expected submodule related functionality

Due to an bug in internal iterator implementation, various submodule related functionality might exhibit unexpected and invalid behavior. Affected from this are at least:

• Wrong alarms are sent on an AR  when plugging submodules. E.g with gaps between them: AR expects Submodules in Slot 1, 2 and 3, Slot 2,3 are not configured and submodule is plugged to Slot 3. (Subslot always 1, all same api) The Alarm for Slot 2 will be seen
• When an AR connects or Dynamic Reconfiguration Sequence is started, unexpected behavior on submodules in AR or submodules assigned to other AR might occur including wrong release/controlled alarms
• When an AR aborts, submodule ownership might be assigned an another AR which did not expect them.
• Module Diff block might contain invalid/unexpected content
• System Redundancy Primary/Backup changes might result in taking ownership of wrong modules.
• ProfiEnergy Alarms might be for wrong modules sent

All the problems above are taken from the source code. It might be difficult to reproduce each particular case. Generally a submodule configuration with gaps between configured submodules and expected submodules is required: Some expected submodules in the middle (ordered by api, slot, subslot) must be missing in real submodule configuration for the problems to show up.