[stable33] authoritative share - revival

[artonge]

Reverts #59172 to have a PR for #58894 again.

Backports of

• Make share mount provider authoritative #57523
• Share mount validation fixes #57745
• Authoritative setup improvements #57578
• feat: perform share mount validation on share instead of on mount #57295
• Active share validation/authoritative mount improvements #57760

[artonge]

Adding Arthur's comment

[blizzz]

Adding Arthur's comment

Thanks! Additionally, those changes need to go be added to https://github.com/nextcloud/documentation/blob/master/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_33.rst respecitvely https://github.com/nextcloud/documentation/blob/master/developer_manual/app_publishing_maintenance/app_upgrade_guide/upgrade_to_34.rst

I am already adding the pending docs label.

[icewind1991]

Added backport of #58207

[salmart-dev]

There is still a bit of a problem with removing this from here: when a room or deck shares are created and during the recipients' mounts update or any other call we end up calling setupForUser or setupForProvider, which resolve the share with the target containing the placeholder. This logic before was patching the target through the moveShare call performed down the line because of the updated target.

Not sure what a fix for those would be, besides having talk and deck proactively creating a user-row for shares when they are queried for a recipient. It shouldn't be a big deal since anyways this was done whenever verifyMountPoint was called the first time.

[salmart-dev]

@icewind1991 ⬆️

[icewind1991]

When explicitly triggering this case with 'debug.force-full-fs-setup' => true, 'debug.optimize-authoritative-providers' => false. It does indeed register a {TALK_PLACEHOLDER} mountpoint during the fs setup, but this then immediately gets fixed by ShareTargetValidator::updateFileTarget