When creating relationship types don't munge names

[alifrumin]

Overview

as @agh1 points out here this change #12097 made on May 8, 2018 made it so relationship types names get munged. This change reverts back to not munging relationship type names.

Before

Creating a Relationship type for example:

Results in the Relationship type names being munged see name_a_b and name_b_a below:

{
    "id": "17",
    "name_a_b": "banana_peeler_is",
    "label_a_b": "banana peeler is",
    "name_b_a": "banana_peeler_for",
    "label_b_a": "banana peeler for",
    "is_active": "1",
    "is_error": 0
}

After

When creating a Relationship type names are not munged see name_a_b and name_b_a in the example below:

{
    "id": "17",
    "name_a_b": "banana peeler is",
    "label_a_b": "banana peeler is",
    "name_b_a": "banana peeler for",
    "label_b_a": "banana peeler for",
    "is_active": "1",
    "is_error": 0
}

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[demeritcowboy]

This was tested alongside #13916, with both patches applied.

[eileenmcnaughton]

I dug a little & still think this was done on a 'this seems like better practice' rather than a real reason so I'm happy to merge this reversal.

However, I would note that if #13916 relies on labels always matching names that could be a problem since a) the data model doesn't require it & b) any types saved 'recently' will be different

[agh1]

@eileenmcnaughton no #13916 doesn't require this--it just highlighted it as a potential oddity. Once @alifrumin and I were done with it, case types still use labels and only labels.

[demeritcowboy]

@eileenmcnaughton It's broken currently anyway in that label always has to match name. You can't change the label of a case role currently in civi without problems.

[demeritcowboy]

I mean it's fine if they're different when created, but then you can't ever change it.

[eileenmcnaughton]

@demeritcowboy @agh1 ok cool - well it does seem like merging this will save future confusion

[eileenmcnaughton]

@demeritcowboy doesn't the wrapping in if (empty($params['id'])) mean it still won't change?

[demeritcowboy]

Give me a minute to write this out in english properly...

[demeritcowboy]

Ok I tried to shorten it to remove the rambling which I tend to do. How does this sound:

Current situation, without either PR:
Name and label can be different to start.
If you then change the label it causes problems, but related to the xml not the fact that the empty check prevents $params['name_x_x'] changing. One example is described in #14001.

After 13916:
That's all still the same, but additionally you have a problem if the name and label are different even to start.

[demeritcowboy]

Or yeah I might be wrong about the AFTER part, in which case oops 13916 doesn't rely on this. Having said that, once this was put up as a PR I did my testing with both applied locally.