Refactor share backend to be more efficient

[CarlSchwan]

Summary

Instead of making queries in each providers, do it once in the manager depending on the providers enabled and then only create the share objects in the share providers.

Additionally introduce a new API for iterating not based on offset but on max_id, min_id

TODO

• Make it work xD

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

[icewind1991]

For dealing with provider specific logic, such as the per-user child shares for groups/teams/etc. It might be worth looking at how the filecache search does it.

It allows the cache instance to customize the filtering by overriding Cache::getQueryFilterForStorage.

So instead of implementing the various share filtering options in the share manager, we could have something like IShareProvider::getSharedWithFilter(IUser $user, IQueryBuilder $builder) etc.
The provider can then do all the custom logic it needs (like figure out the groups for a user) and build the query part.
The share manager then combines all the query parts in an orX to fetch everything at once.

[CarlSchwan]

Internal discussion: This is helpful but we are planing to overhaul/rewrite sharing for 34 and the new implementation will be build from the ground up without this limitation