Store all known users from all user managers in a single table

[PVince81]

Current issue in a LDAP scenario (also applies to other user managers):

1. Only local users are stored in oc_users
2. LDAP users are stored separately in mapping tables, the tables are LDAP specific
3. No easy way to work with all users on SQL-level (repair steps, etc)
4. On PHP level, additional round trips required to all user managers when doing user searches, for example for share autocomplete

Proposed solution:

Either reuse oc_users or provide new tables to store all users (and maybe groups too) that are known to this ownCloud instance. The table itself will have a "externalUserId" and "externalUserType" to be able to link it to other user-manager specific tables (ex: LDAP).

Ref: #19600 (comment)

@DeepDiver1975 @karlitschek @blizzz @icewind1991 @schiesbn @rullzer

[PVince81]

This is also important to be able to properly map users to their storages. Currently LDAP users have no entries in oc_users, so if you start with a storage in the DB and want to go back to the user data you're out of luck.

[DeepDiver1975]

related #18227

[blizzz]

oc_users are and should be kept for local users. There are other information we like to store as well in a unified way and still user backends will continue to take care of their affairs (managing users) in their systems. So it's best to imagine oc_users is an external resource as well.

#19600 mixes up user names and login names. The problem is programtic: developers used to expect that the login name matches the user name which is even not always true for internal users as you can login with JABBAtheHUTT but your username still is 'jabbathehutt'.

In that table we can store all the user related information, like displayname, email, maybe user directory path, and keep the user backends in charge to keep the information up to date. It will be difficult for search, because user backends (like LDAP) offer more advanced search functions that are run on backend side. For just internally done searches (in user or display names) the table will suffice.

[MTRichards]

The bigger sledgehammer needs a milestone so it gets considered. Setting to 9.1.

[schiessle]

With the new auto-complete for federated sharing across ownClouds we create a carddav address book with all system users. We can use this address book in the future for other stuff as well.