Introduce dn search filter and use it for memberuid value lookup

if this group and user are present

# Box66, groups, owncloudqa.com
dn: cn=Box66,ou=groups,dc=owncloudqa,dc=com
objectClass: posixGroup
cn: Box66
gidNumber: 10066
description: Group account66
memberUid: aaliyah_adams

 > ldapsearch -h "server:port" -b "ou=people,dc=owncloudqa,dc=com" -w password -x -D "cn=admin,dc=owncloudqa,dc=com" '(uid=aaliyah_adams)' '*' memberof entryuuid

# aaliyah_adams, people, owncloudqa.com
dn: uid=aaliyah_adams,ou=people,dc=owncloudqa,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: aaliyah
sn: adams
userPassword:: base64 encoded {SSHA}...
uid: aaliyah_adams
displayName: aaliyah adams
memberOf: cn=Box66,ou=groups,dc=owncloudqa,dc=com

OC will detect and use memberuid as the Group-Member association

If the Login Attributes tab shows the LDAP / AD Username checkbox as unticked the login filter might look something like:
(&(&(|(objectclass=inetOrgPerson))(|(mailPrimaryAddress=aaliyah_adams)(mail=aaliyah_adams)))(|(mail=*)(othermailbox=*)))

It will be used to look up the dn for the user with the value from the memberuid attribute, eg. aaliyah_adams. Since the filter does not contain the uid / cn, the user does not show up as a member of the group.

The filter is created here: https://github.com/owncloud/user_ldap/blob/f1a83937dfe897467fe19797c19f13a85495b7f9/lib/Group_LDAP.php#L653-L657

A workaround is to add the uid or cn attribute to the additional search terms, tick the LDAP / AD Username checkbox, or manually edit the ldap login fitler (and live with the consequences of either workaround)

The proper fix is to intreduce a distinct lookup filter that always uses the uid / cn.

Start in lib/Group_LDAP.php at the filter construction around lines 653-657 and trace how memberUid values are resolved to user DNs. Introduce the distinct lookup filter described in the issue, ensuring it always searches with uid or cn so the user is recognized as a group member.