Flexibilize matching of external user ids and Nextcloud users (SAML, OIDC to LDAP)

The scenario is: When user A logs in via SSO/SAML the external identity provider submits a user id. An LDAP server is often connected to Nextcloud and is backing the logged in user. So when the login happens we have to exactly match the external uid with the Nextcloud internal user id. When a UUID is being used, there is typically no problem. It is not unlikely though that in some setups different values are being used (like last names, email addresses) or UUIDs change due to LDAP server migrations (not all products allow to specify an UUID). We do see cases about this regularly. Recently, the OIDC backend faces the same situation.

The suggestion to resolve the issue is the following:

• The existing ILDAPProvider is extended with a "findOneUser" method. It shall execute the search for one user based on either a provided LDAP filter, or a provided combination of an attribute and a search term. When exactly one match is found, the IUser object will be returned. If none is found, the return value is null. If more a found a specific exception is being thrown.
• The LDAP backend's implementation of the ILDAPProvider will obviously be equipped with the concrete implementation of above.
• Other login backends that may rely on LDAP, like the SAML/SSO or OIDC backend, will get an additional configuration option to specify an attribute to which the received user id is being compared. When an admin configured it, and an LDAPProvider is available, upon login the backend will try to resolve the user with the afore mentioned method. If no user was found the regular procedure continues, if more than one user were found (exception case) it will be logged accordingly, and the Not Provided error will be shown (background: prevent data leakage).

Performance impact: The scenario is on login only, but even there the impact is not negative. On the contrary it can have a positive impact. This is because on login, we (SAML, OIDC) execute a user search to serve the case that potential new users are being imported to Nextcloud so that a login will not fail. With this new approach this search will not be necessary anymore (the direct lookup will import the user, too), for it is being replaced by a slimmer and more direct search filter: it will contain only one search attribute and no trailing wildcard.
There is further potential to not always look the user, but save the resolved user ids at least for some time after reading them once.

Related: https://github.com/nextcloud/user_saml/issues/563

Discussed previously with @come-nc and @julien-nc

Start by tracing the ILDAPProvider interface and its LDAP backend implementation, then inspect the SAML and OIDC login backends that resolve external user IDs. Clarify the single-match, no-match, and multiple-match behavior described in the issue, including logging and the Not Provided response. Done means the configured attribute or filter can resolve the intended LDAP-backed user without weakening ambiguous-match handling.