https://fedorahosted.org/sssd/ticket/1818

I have here a LDAP user entry which has this attribute

	loginAllowedTimeMap::
	 AAAAAAAAAP///38AAP///38AAP///38AAP///38AAP///38AAAAAAAAA

In the function sysdb_attrs_add_string(), called from
sdap_attrs_add_ldap_attr(), strlen() is called on this blob, which is
the wrong thing to do. The result of strlen is then used to populate
the .v_length member of a struct ldb_val - and this will set it to
zero in this case. (There is also the problem that there may not be
a '\0' at all in the blob.)

Subsequently, .v_length being 0 makes ldb_modify(), called from
sysdb_set_entry_attr(), return LDB_ERR_INVALID_ATTRIBUTE_SYNTAX. End
result is that users do not get stored in the sysdb, and programs like
`id` or `getent ...` show incomplete information.

The bug was encountered with sssd-1.8.5. sssd-1.5.11 seemed to behave
fine, but that may not mean that is the absolute lower boundary of
introduction of the problem.

Also rename it to sysdb_attrs_get_el_ext()

Fixes a regression in the local domain tools where sss_groupadd no longer
detected a GID duplicate. The check for EEXIST is moved one level up into
more high level function.

The patch also adds the same rename support for users. I found it odd that
we allowed a rename of groups but not users. There is a catch when storing
a user -- his cached password would be gone. I think that renaming a user
is such a rare operation that it's not severe, plus there is a warning in
the logs.

https://fedorahosted.org/sssd/ticket/1253

https://fedorahosted.org/sssd/ticket/1228

https://fedorahosted.org/sssd/ticket/1136

https://fedorahosted.org/sssd/ticket/1173