This add support for the following graph routes:
POST /drives/{driveID}/root/createLink
DELETE /drives/{driveID}/root/permissions/{permissionID}
PATCH /drives/{driveID}/root/permissions/{permissionID}
and
POST /drives/{driveID}/root/permissions/{permissionID}/setPassword
This should significantly improve handling of permissions on spaces
as there is no need to figure to the drive's root itemid anymore.
Partial Fix: #8351
BaseGraphService is a struct to hold common fields and methods that can be
share between different service implementations. E.g. for converting CS3 objects
to their libregraph equivalents.
This introduces the new DriveItemPermissionsService and DriveItemPermissionsApi to
allow for better separation of the business logic and the API handling.
As a starting point the Invite method was moved to the new service. More to follow.
In order to work with (e.g. get/delete) permissions granted to space
we need to give them a stable id. As the CS3 API don't provide an id
we generate it base on the id of the identity that the permission applies
to. For users we use "u:<userid>" for groups "g:<groupid>".
Closes: #8352
This reworks the cs3PermissionsToLibreGraph() so that it is able to return
the libreGraph.Permissions in the legacy and the new v1beta1 format. The main
differences between both are that v1beta1 returns the identities in the
'grantedToV2' property and the 'roles' are returned as IDs instead of the
legacy role names.
When accepting a share via 'POST /v1beta1/drives/{driveId}/root/children'
return the newly created driveItem. This driveItem wraps the accepted
remoteItem representing the shared resource (similar to the
'sharedWithMe' response.
This also refactors some of the helpers for user lookup and CS3 share to
driveItem conversion so they can be more easily shared.
In theory creating the driveItem to accepting a shared resource
can be done via '/v1beta1/drives/{drive-id}/item/{item-id}/children'
but there is also the simplified variant via
'/v1beta1/drives/{drive-id}/root/children' (aligned with the example
in the spec). For now we'll just implement the latter because accepting
a share will always be done via root of the sharejail drive.
