#8513 Properly pass epic name into isolation function, so that muteState has all the epics listed correctly.

[alexander-fedorenko]

Description

There is an issue preventing epics from being muted correctly because epics name is not passed as an argument into function that creates RxJS subject per epic.
Also, when plugin name is not normalized in plugins.js, mute of the epic can't happen properly under specific conditions.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

What is the current behavior?
#8513

What is the new behavior?
Mute/unmute action is managed properly regardless of plugin name. All epics are isolated properly.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

[alexander-fedorenko]

Hi @allyoucanmap, please review it when convenient.
As previously discussed, test coverage is extended now to cover storeManager main use-cases.

[allyoucanmap]

@tdipisa there is not a specific test to do for this on the DEV, this is related to the new store API. We could verify if the application is loading as usual

[tdipisa]

@tdipisa there is not a specific test to do for this on the DEV, this is related to the new store API. We could verify if the application is loading as usual

@ElenaGallo please proceed as usual in DEV and let us know for the backport. Thank you @allyoucanmap.

[ElenaGallo]

Test passed on DEV, @allyoucanmap please backport to stable branch. Thanks

[alexander-fedorenko]

@tdipisa, @ElenaGallo this cannot be effectively backported to 2022.02.xx because #8457 (comment) is not yet backported.

[tdipisa]

@tdipisa, @ElenaGallo this cannot be effectively backported to 2022.02.xx because #8457 (comment) is not yet backported.

Yes I know @alexander-fedorenko. Why did you backport it anyway without providing a backport also for 8457?

@ElenaGallo before backporting #8457 all tests for #8503 must pass.