fix: check against memberUid instead of posixGroup

[jvillafanez]

posixGroup might be set up as an auxiliary class, and the oCIS configuration might target a structural class such as groupOfNames. This means that the memberUid attribute might appear in groups configured with groupsOfNames, not just with posixGroup.
We'll look for usernames if the group membership is configured as "memberUid" in oCIS regardless of the specific object class for groups.

---

NOTE: In LDAP is possible to configure groups containing "member" and "memberUid" attributes at the same time, both of them targeting different users. However, oCIS is currently expecting only one group membership attribute.
In this scenario, it's expected that only the users in the configured oCIS' group membership attribute (either "member" or "memberUid") are shown, while the rest of users are ignored.

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[LukasHirt]

GetLDAPGroupMembers still branches on Objectclass == "posixgroup"

identity.go#L470 — this is the same bug GetLDAPUserGroups had before this fix. With group_schema.member = "memberUid" and group_objectclass = "groupOfNames", member values are bare usernames, but this branch takes the else path and passes them to GetLDAPUserByDN as if they were DNs, so the lookup fails and the member is silently dropped. Group member listing ends up empty/incomplete for the config this PR targets.

Should this get the same Schema.Member check?

[jvillafanez]

Should this get the same Schema.Member check?

Yes, you're right. It's fixed now.