autoaccept groups shares may create too much load and not finish all accepts

The current implementation for autoaccept shares needlessly amplifies writes. On a group share with 5k members 5k writes are made to update the received shares status, at least one per member.

Furthermore, when the autoaccept logic iterades over members and is killed by kubernetes it may not have accepted all shares. It will not pick that up because we fetched the event from the queue and ACKed it automatically.

A better solution would be to move the autoaccept code to the share manager implementation itself: whenever a list received shares call is made we already fetch all group shares the user is a member of before fetching the received state for each share (that contains the mountpoint and the pending / accepted / rejected state). We can update any pending shares to accepted on the fly.

This would

* (PRO) reduce the number of writes to the amount of active users
* (PRO) move the functionality to a storage manager implementation, where it belongs
* (PRO) get rid of an event based mechanism that AFAICT may overload the underlying storage
* (PRO) solve data inconsistency whan a group share accept operation was killed by kubernetes while still iterating over the members
* (CON) force every share manager implementation to implement autoaccept on its own.

IMO a reasonable tradeoff.