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

It is possible to simply reset the list of ghost users to a different one
during a modify operation. It is also actually how we update entries that
are expired in the SSSD cache.

In this case, we must be careful and retain the ghost users that are not
native to the group we are processing but are rather inherited from child
groups. The intention of the replace operation after all is to set the
list of direct members of that group, not direct and indirect.

Similar to the add and delete operation, we also need to propagate the
changes of the ghost user attribute to the parent groups so that if a
nested group updates memberships, its parents also get the membership
updated.

This new function will be reused by the modify operation later

This new function is going to be reused by the modify operation

This will allow to process ghost users in a similar fashion

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

The memberof plugin did only expand the ghost users attribute to
parents when adding a nested group, but didn't implement the reverse
operation.

This bug resulted in users being reported as group members even
after the direct parent went away as the expanded ghost attributes were
never removed from the parent entry.

When a ghost entry is removed from a group, all its parent groups are
expired from the cache by setting the expire timestamp to 1. Doing so
would force the SSSD to re-read the group next time it is requested in
order to make sure its members are really up-to-date.

When a nested group with ghost users is added, its ghost attribute should
propagate within the nested group structure much like the memberuid
attribute. Unlike the memberuid attribute, the ghost attribute is only
semi-managed by the memberof plugin and added manually to the original
entry.

This bug caused LDB errors saying that attribute or value already exists
when a group with a ghost user was added to the hierarchy as groups were
updated with an attribute they already had.

Large memberof delete operations can cause quite a number of searches
and the results are attached to a delop operation structure.
Make sure we free this payload once the operation is done and these
results are not used anymore so that we get a smaller total memory footprint.

We were skipping the check on the next value in the added list when a match
was found for the currentr value being checked.