Normalize layers/groups management in TOC #10247

[rowheat02]

Description

fixes: #10247.
Some old maps and exports have groups in legacy format which shows some bugs like those mentioned in #10247.
Old formats can be converted to new standard formats with UI-wise invisible default group as a parent of all groups.

legacyGroups = [
  { id: '1', name: 'Group 1' },
 { id: DEFAULT_GROUP_ID }
 ];

newStandardFormat=[
      {
          id: <DEFAULT_GROUP_ID>,
         name: <DEFAULT_GROUP_ID>,
        nodes: [
             { id: '1', name: 'Group 1' },
             { id: 'DEFAULT_GROUP_ID.DEFAULT_GROUP_ID' } // Unique UUID generated
         ],
        expanded: true
    }
 ]
 

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?

#10247
There are some interactivity bugs on TOC in old maps and exports.

What is the new behavior?

There are no interactivity bugs on TOC in old maps and exports.

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

[rowheat02]

@tdipisa

• This PR solves the bugs mentioned here Normalize layers/groups management in TOC  #10247
• Now the conversion is done considering groups from this map.https://dev-mapstore.geosolutionsgroup.com/mapstore/#/viewer/39079. Are there any other maps with TOC bugs to verify?

[tdipisa]

@allyoucanmap it seems @rowheat02 is waiting for your feedback to unblock and finalize this PR. Can you please have a look?

[allyoucanmap]

This changes in this PR are technically making the presented cases in the issue work but it's not addressing this part:

As part of this issue is definitely requested to provide also the necessary clean up for completely removing the concept of "default group" to make also old maps consistent with new TOC behaviors.

The solution provided is adding a group prefix to the default group resulting in a new group id (Default.Default) that it making it works someway.
We should instead understand the following:

• Why the default group has the sort handler blocked?
• Why the sort/move action used by the TOC is preventing the default to be moved?
• Why the sort/move action used by the TOC is preventing the layers to be placed in the root?
• Is it possible to remove the concept of Default group and place nodes (groups and layers) inside the TOC root?

We need to take this issue to really understand the problem related to groups and layers in TOC and if needed also refactor logic and component.
I think we could accept this PR only once we answered the questions above and there isn't other alternatives.

---

Side note:
Usually group ids in mapstore are following this structure parentGroupId.groupId but it seems with the proposed changes we are adding the following case, where group01 and group02 don't have a the parentId group:

[
    {
        "id": "Default",
        "name": "Default",
        "nodes": [
            {
                "id": "Default.Default",
                ...
            },
            {
                "id": "group01",
                ...
            },
            {
                "id": "group02",
                ...
            }
        ]
    }
]

We need also to understand and investigate why is this still working

[rowheat02]

This task will be placed on hold for the following reasons.

Currently, there is a single group wrapper named "Default," which is not visible in the UI. This wrapper supports all utility functions related to adding/moving nodes, exporting, and importing configurations from the existing codebase. The legacy system's default group (node) can coexist with other sibling groups. Additionally, there is the concept of a "root group" for nodes that are not assigned to any group. Two potential solutions to make it compatible for both new and legacy format of nodes have been identified, both of which involve breaking changes and require careful updates to old utility functions, followed by thorough testing.

Solution 1: Include both layers and groups in the group state, as the group state serves as the starting point for the Table of Contents (TOC) UI. However, this approach would disrupt all legacy utility functions that assume the group state should only contain groups as level-one nodes.

the format that every util function supports ( all group nodes as level one child in group state)

[
  {
    "id": "group node 1",
    "nodes": [
      {
        "id": "layer node 1"
      }
    ]
  },
  {
    "id": "group node 2"
  }
]

format proposed which breaks every util functions( layer node in group as level one child)

[
  {
    "id": "group node 1",
    "nodes": [
      {
        "id": "layer node 1"
      }
    ]
  },
  {
    "id": "layer node 1"
  },
  {
    "id": "group node 2"
  }
]

Implementing this would require a deep understanding of all utility functions and meticulous updates to ensure compatibility.

Solution 2: Introduce a root group that can wrap the Default group and other sibling groups while hiding it in the UI.

{
  "id": "root",
  "node": [
    {
      "id": "Default",
      "nodes": [
        {
          "id": "layer node 1"
        }
      ]
    },
    {
      "id": "layer node 1"
    },
    {
      "id": "group node 2"
    }
  ]
}

However, this adds an additional layer of hierarchy, which could complicate maintenance. It also risks breaking the format and functionality during the export and import of configurations.
Both solutions involve significant changes and need careful updates to legacy utility functions, along with extensive testing.

[allyoucanmap]

@rowheat02 @tdipisa, leaving this for the future, both solutions 1 and 2 should not taken as the only ways to solve this problem because they are just a results of internal discussion. Some important points and finding for this task:

• the groups sorting in the TOC root container could be solved by removing some constraint in the UI and functions while the sorting for layers at root level needs refactor in legacy utility function
• a refactor of involved utilities function is needed both for readability and to better understand the sorting workflow
• the exported and imported map configuration should always be consistent. So it's important to evaluate carefully the new properties/structures we want to introduce (if we need to). For this reason I would avoid the solution 1 if possible
• at the moment the groups structure is always derived by the layers configuration. This is computed inside the getLayersByGroup function
• the current duality of root and default group concept should be reduce to a single type of "default" group. In general if we are going to add a layer with group property undefined we should expect this layer in the first level of the TOC without parent groups node