Group listing fails when a user is not available

[blizzz]

Steps to reproduce

1. Have a group containing LDAP users
2. Remove one of those user from LDAP
3. Request group memberships via ProvisioningAPI/Users page

Expected behaviour

They should be listed

Actual behaviour

page stays empty, cause by an uncaught exception thrown from User_LDAP::getHome, because it does only return the home path on deletion processes (for reasons i guess).

[blizzz]

That's a bit nasty. The root of all evil is that when a user should be deleted, the core manager first checks whether the user exists. In case of external user repositories it is that the original record vanishes and we do no want to operate with it anymore. At the same time we cannot be sure why the user is not present anymore, it might be a glitch. Auto-deleting would be too dangerous. Thus, LDAP must say "yes" when it is asked whether a user exists, even if it does not on LDAP, to be able to offer a deletion routine within the user api.

Then there, is the homePath() call which provides the path to the home folder. Due to the situation above we'll get into this method. For existing users, the configured path is returned. For deleting it is necessary to return the last known path for users that are deleted on LDAP. In a non-deleting case we throw an NoUserException.

This now kicks in. However, it does not really make sense to successfully retrieve an IUser object, and only upon call of getHome() be confronted with that Exception. It is neither intuitive nor documented.

The simpler thing would be to always return that path. There was an attempt in #5689 which did not turned out to be successful. We may run into side effects while operating with undead user representation (given, I don't remember which exactly, but it'll be storage related).

For a backportable fix, big structural changes should be avoided. A quick fix for this case is possible, but not exactly sustainable. I fancy to move the delete method from the user to the user manager, where it make syntactically most sense. Alas, this is something for 16 (or generally considering such a user state).

For now I wrap the path retrieval in ProvisioningAPI's AUserData, throw a OCSNotFoundException, catch it in the caller that walks through the users of the specified group and ignore that. That's small, not too bad, but long term there should be a better handling of this user state in general. There are too many hacks around that already.

[MorrisJobke]

Fixed by #13644

@blizzz Reopen if wrong.