Handle special characters in content type group (EZP-30422)

[bdunogier]

https://jira.ez.no/browse/EZP-30422

Changes the normalization of content types groups identifiers to transform all non alphanumeric characters to _. It is required on content types groups identifiers as they are actually human readable names.

TODO

• Decide if we want to handle other types of special characters (such as accentuated, or even asian). Should we transliterate those ? If yes, using what ?

[mnocon]

Tested with characters like -_!$%^&*()?/~§£=-`, looks ok to me.

Two things:

1. have you made any decision about the TODO?
2. If I create two groups: "Marek Nocoń" and "Marek-Nocoń" they are merged into one that has Content Types of both of them (for example: Marek Nocoń has Content Type folder111 and Marek-Nocoń has Content Type folder2222). There is only one group available (example query:

{
  marekNoco_ {
    _info {
      identifier
    }
    folder111s {
      edges {
        node {
          _name
        }
      }
    }
    folder2222s {
      edges {
        node {
          _name
        }
      }
    }
  }
}

which returns

{
  "data": {
    "marekNoco_": {
      "_info": {
        "identifier": "Marek Nocoń"
      },
      "folder111s": {
        "edges": []
      },
      "folder2222s": {
        "edges": [
          {
            "node": {
              "_name": "2"
            }
          }
        ]
      }
    }
  }
}

As I'm not sure if we can avoid this (and whether this could become an issue) I'm just pointing it out, to double check that we're ok with this behaviour.

[bdunogier]

have you made any decision about the TODO?

No, not yet. In any case, the fixed code is an improvement over the previous one, we don't have to decide right now I guess.

If I create two groups: "Marek Nocoń" and "Marek-Nocoń" they are merged into one that has Content Types of both of them

That's what I call QA ! :)
The result is surprising, and I gotta admit, surprisingly good. I'd have expected one of them to be missing...

I'm not sure how we want to address that, and I probably wouldn't block this PR for that. We may have to decide at some point. The way I see it, there'll always be edge cases with the normalization we do, and the only reliable solution will in the end be to allow to customize names.

[lserwatka]

Let’s call it stage 1.