Implement PoC (proof of concept) of the State Management that increase performance

[korel-san]

The main goal of the task: create State Service that contains the parsed actual route state.

More details:
The routing state depends on the page and functionality of the page. Now many components trying to parse it, which increased code duplication and worked not properly in some cases. So, for the unification of the actual routing state, we consider separating functionality in service, which would handle the actual route state, and every component would be asked from its real data for their purposes.
We don't want to use current state management ngrx due to the high level of tied dependency of the current implementation, so not to add extra naming and have a more lightweight solution, we want to use another tool for this PoC will allow us to not affect the current performance.

Actual implementation plan:

1. investigate 2-3 state management packages: elf, effector, ng-state
   Points on which we need to focus

• it should be lightweight
• it should be pretty simple
• package should allow to manipulate of routing (subscription, session storage)

2. create a state folder in the src and add there actual-route-state.repository.ts. In this file, we need to create a repository that would manage the routing state. Please, take into account, that this state management should work only for the local environment. On prod env, this instance should not exist.
3. In some cases probably you will need to create Adapters that would convert the current routing state to a meaningful one. For example for pages where we have protected query parameters via the encoding of StringHelpers.encodeObjToUrlString. So after this implementation, every developer should be allowed to see the state of this service on every page of the project.

[wajda]

Please, take into account, that this state management should work only for the local environment. On prod env, this instance should not exist.

As discussed, please don't do that. Instead, keep the codebase environment independent. If you don't want some PoC logic to be merged into the main branch and with that become a part of production then the best way would be to simply keep it in a branch (or even in a personal fork if you prefer) until it's ready. Any conditions like env=dev/prod/qa etc should be avoided. The code running on all env should be exactly the same for the sake of logic consistency, predictability, ease of testing and troubleshooting.