* Add integration tests for double shares with rename in between

* Make share target consistent when grouping group share with user share

In some situations, a group share is created before a user share, and
the recipient renamed the received share before the latter is created.
In this situation, the "file_target" was already modified and the second
created share must align to the already renamed share.

To achieve this, the MountProvider now groups only by "item_source"
value and sorts by share time. This makes it so that the least recent
share is selected as super-share and its "file_target" value is then
adjusted in all grouped shares.

This fixes the issue where this situation would have different
"file_target" values resulting in two shared folders appearing instead
of one.

Add integration test for the use case where a group share exists and
then the same owner creates a direct share to a user in that group.

Link shares always allowed deletion, however internally the permissions
were stored as 7 which lacked delete permissions. This created an
inconsistency in the Webdav permissions.

This fix makes sure we include delete permissions in the share
permissions, which now become 15.

In case a client is still passing 7 for legacy reasons, it gets
converted automatically to 15.

Signed-off-by: Stefan Weil <sw@weilnetz.de>

Fixes https://github.com/owncloud/core/issues/23741

Scenario:
user0 shares a folder 'foo' with user2
user1 shares a folder 'foo' with user2
user2 logs in

Before: show only the 'foo' from user1

After: show both.

* Added intergration tests

This property can be queries by the clients so they know the max
permissions they can use to share a file with. This will improve the UX.

The oc:permissions proptery is not enough since mountpoints have
different permissions (delete + move by default).

By making it a new property the clients can just request it. On older
servers it will just return a 404 for that property (and thus they know
they have to fall back to their hacky work arounds). But if the property
is returned the client can show proper info.

* unit tests
* intergration test

Fixes #22675

Since we only get a share id we do not know the path for the sharer.
Now if we edit a share we start searching for shares for that user of
that node. And deduce the permissions that way.

* Intergration test added
* Fix unit tests

* Updated unit tests
* Added intergration test

Sharing of the users root folder should not be allowed as it is very
weird UX. Also many of our clients have no proper way of displaying
this.

Added unit test

Also added intergration tests to make sure we won't allow it in the
future.

* user with a quota of 0 gets a file shared and can't update this file
  because the wrong quota is used to verify if the update is allowed

The new sharing code handles things differently so there is no way for
create shares to handle this all properly.

* Small changes plus check of the file using propfind
* Restaured line removed accidentally