Remove inefficient fed share scanner

[PVince81]

Remove scanAll which relies on the "shareinfo" endpoint that returns the
full cache tree.
The latter can become big for big shares and result in timeouts.
Furthermode, the full tree would be retrieved again for each and every
detected change which can become expensive quickly.

As discussed with @icewind1991

Draft for now, needs more extensive testing to confirm that the default scanner will work correctly for federated shares.

Fixes #29941

[PVince81]

cool, no failure related to federated sharing

• still need a bit more manual testing though, especially with deeper folder structures and also see how the desktop client reacts

[PVince81]

I've done a manual test as follows:

1. Setup two instances A and B
2. Setup user alice@A
3. Setup desktop client for alice
4. Login as admin@B
5. Create a folder "a/b/c/d"
6. Share "a" with alice@A
7. As alice, accept the share
8. Wait for sync
9. As admin, create a new folder "a/b/c/d/e"
10. Wait for sync

After the sync, the new folder "e" got synced.
I've also observed that the etag changes properly in the receiving end's storage.

So it all works fine with this PR 😀

Please review!

[skjnldsv]

Needs a rebase, but all good 🚀

[PVince81]

JS failure unrelated, merging

[solracsf]

Does this qualify for backport?

[PVince81]

/backport to stable23

[PVince81]

/backport to stable22

[PVince81]

/backport to stable21

[PVince81]

Does this qualify for backport?

thanks for your usual reminders 😄

[juliusknorr]

@PVince81 FYI it seems there is a regression where uploading files or creating folders is not possible anymore with this on the receiving side: #31554 Bisecting showed this commit and reverting makes it work again.