feat(groups): transitive group-in-group membership

[KiaraGrouwstra]

Adds transitive group-in-group membership to the database group backend. A group can be made a direct subgroup of another group via a new group_group(parent_gid, child_gid) edge table. Membership composes transitively: a user in a subgroup is an effective member of every ancestor.

Existing getUserGroupIds / getUserGroups semantics are unchanged; a new getUserEffectiveGroupIds is introduced for call sites that should honor nesting. Only OC\Group\Database implements the new internal INestedGroupBackend capability interface; LDAP, SAML and other external backends are untouched.

Part 1 of a series implementing #36150. Follow-up PRs layer sub-admin delegation, access-check migration, OCS endpoints, and admin UI on top.

What is in this PR

• Migration Version34000Date20260410120000 -- creates group_group(parent_gid, child_gid) and group_group_admin(admin_gid, gid) tables.
• OC\Group\Database -- addGroupToGroup / removeGroupFromGroup / getChildGroups / getParentGroups / getChildGroupsBatch / getParentGroupsBatch / groupInGroup / isDescendantOf. Cycle check + insert wrapped in a serialized transaction so concurrent writers cannot race a cycle into existence.
• OC\Group\Manager -- BFS transitive closure with per-request memoization and batched backend queries (one WHERE IN per BFS level). addSubGroup / removeSubGroup dispatch SubGroupAddedEvent / SubGroupRemovedEvent plus per-user UserAddedEvent / UserRemovedEvent for every user who gains or loses effective membership (bounded by MAX_SYNTHESIZED_USER_EVENTS = 500).
• Public API on OCP\IGroupManager: getUserEffectiveGroupIds, addSubGroup / removeSubGroup, getDirectChildGroupIds / getDirectParentGroupIds, getGroupEffectiveDescendantIds / getGroupEffectiveAncestorIds.
• Events: SubGroupAddedEvent, SubGroupRemovedEvent.
• Exceptions: CycleDetectedException, NestedGroupsNotSupportedException.
• Documentation: lib/private/Group/NESTED_GROUPS.md covering concept, cycle prevention, event synthesis, and caveats.

Caveats (documented in NESTED_GROUPS.md)

• Encryption re-keying cap -- beyond 500 users, per-user events are skipped and a warning is logged; admin must run a manual re-key pass.
• Delete-middle-group -- deleting B in A -> B -> C drops both edges without splicing.
• LDAP enumeration cost -- collectEffectiveUserIds walks descendants via searchUsers(''); nesting a large LDAP group may block the request.

Test plan

• tests/lib/Group/NestedGroupsTest.php -- transitive closure, diamond dedup, cycle rejection, idempotent add, event dispatch, cache invalidation, direct-child listing.
• tests/lib/Group/DatabaseTest.php -- nested CRUD, self-edge rejection, cycle rejection, edge cleanup on group deletion.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[nickvergessen]

Sorry, meant to comment already last week.
I'm having some fear with this change from security and app-ecosystem perspective.

There will be a huge mess if this is not dealt with correctly by each app.
So from my POV the existing API must reflect the state without any changes by calling parties, to ensure no additional/unexpected data/access whatever is leaked.

Server-side encryption

If apps/encryption is enabled, nested-group mutations may leave the
key distribution out of sync for effective members gained or lost past
the MAX_SYNTHESIZED_USER_EVENTS cap. This is not addressed
automatically; the admin must run a manual re-key pass after bulk
nesting changes on encrypted instances. A prominent warning in
nextcloud.log indicates when this is required.

E.g. this is not acceptable from my POV

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)