feat(files_sharing): implement partial mount providers

[salmart-dev]

Summary

Implements IPartialMountProvider in MountProvider for external files_sharing.

This PR depends on:

• Feature/54562/drop mounts on full or provider setup #57289
• fix: add $forChildren parameter to IPartialMountProvider #57286

Once this PR is merged, all providers that do not implement IPartialShareProvider will stop being called during the setup and shares will disappear. It is important this is merged after all share providers implement #57285

• feat: implement IPartialShareProvider support deck#7501
• feature: implement IPartialShareProvider support circles#2275
• feature: implement IPartialShareProvider support spreed#16655

TODO

• Add tests
• Add indexes for target on oc_share and oc_share_external

[icewind1991]

Do we really need to pass $mountProviderArgs to the getMountsForPath() implementations? Currently, we do not use it.

It's the part that has the actual "real" data about what mounts to setup, $path is "just" the path for which the setup was requested, not the path for which mounts are expected.

It would also be better for performance for mount providers to use the provided CacheEntry (though weaving that into the logic might be non-trivial)

[icewind1991]

I move all the shared logic out of the getMountsForPath() implementations to their caller getUserMountsFromProviderByPath(). Is it a good idea? I don't see in which mount provider we would not do the same.

"All mount provider do the same" and "the way they do it should be part of the api" are two different things that I think shouldn't be conflated.

[artonge]

Returning "to much" should be harmless

If we return too much, should we then register those missing mounts?

[icewind1991]

If we return too much, should we then register those missing mounts?

Probably, determining which of the extra ones are not registered already without extra cost might be tricky though.

[artonge]

Probably, determining which of the extra ones are not registered already without extra cost might be tricky though.

Well, we have the list of registered mount points in $mountProviderArgs (A), and the list of mount point from the provider perspective (B). So anything that is in B and not in A should be registered, no?

[icewind1991]

Well, we have the list of registered mount points in $mountProviderArgs (A), and the list of mount point from the provider perspective (B). So anything that is in B and not in A should be registered, no?

Providers could return mounts that are registered, just not requested.

[icewind1991]

Blocking as per previous comments

Already addressed

[artonge]

• Create issue about registering extra mount providers and removing missing ones - feat(Filesystem): Register extra mount providers in partial FS setup #57567
• Create issue about share provider optimisations - feat(Filesystem): Improve share providers logic #57568
  • Use the $mountProviderArgs instead of joining filecache
  • Now that we join the direct user share, we don't need the group, talk room, deck board loop to check for membership? But when is the user share created or deleted?
  • We can use the $mountProviderArgs[*]->mountInfo->getMountPoint() instead of doing a LIKE ${path}_%

[icewind1991]

Looks good otherwise