Further separation of authentication and synchronization areas in sources

[pboguslawski]

Feature Description

Please consider further separation of authentication and synchronization areas in sources:

(1)
UserSignIn() iterates now over all sources to authenticate user

https://github.com/go-gitea/gitea/blob/main/services/auth/signin.go#L86

It should skip this step if reverse proxy authentication is enabled.

After successful authentication, UserSignIn() should not finish but iterate
over all sources in similar way to find first source that is able to synchronize
user data (create user if doesn't exist) for this user only.

Note: user sync source may be different than authentication source (think of
authenticating user by reverse proxy and fetching user data from ldap source).

(2)
Sync stuff like in

https://github.com/go-gitea/gitea/blob/main/services/auth/source/ldap/source_sync.go

should be refactored to allow sync of one specified user /SyncUser() maybe/ and all users
/maybe SyncAllUsers() instead of Sync()/ and SyncAllUsers() should be simple iteration
of SyncUser() for all users from this source. (1) Should use SyncUser() to synchronize
user data from this source.

(3)
Sync stuff like this

https://github.com/go-gitea/gitea/blob/main/services/auth/source/ldap/source_authenticate.go#L53

should be moved from authentication area to sync area (2).

(4)
2FA should be optional and independent of any auth source (may be not required when reverse proxy is used and its auth used there is secure enough). 2FA may probably by be called in UserSignIn() also after main auth and sync?

Separation of auth and sync areas should allow admin in the future to configure advanced scenarios like authenticate users by reverse proxy (or from a few parallelly used auth backends like sql/ldap dbs - first configured backend that knows user wins) and use a few user sync sql/ldap data backends in parallel (some users from ldap1, some from ldap2, some from sql1, some from sql1, first configured backend that knows user data wins).

Related:
#16199
#18452

Screenshots

No response

[zeripath]

I agree we need to do this.

It's clear that people want directory services so we need to consider this.