Unblocks user when active_directory is disabled and it can be found
We implemented a specific block state to handle user blocking that originates from LDAP filtering rules / directory state in !2242.
That introduced a regression in LDAP authentication when Active Directory support was disabled. You could have a scenario where the user would not be temporarily found (like a filtering rule), that would mark the user as `ldap_blocked`, but will never unblock it automatically when that state changed.
Fixes#14253, #13179, #13259, #13959
See merge request !3550
LDAP Sync blocked user edgecases
Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)
Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.
Expected behavior:
- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:

There will be another MR for the EE version.
See merge request !2242
The Net::LDAP::Filter.escape function can not be used to escape the DN name because the backslash is required to escape special chars in the DN name. This leads to the error message "Access denied for your LDAP account." and prevents the user from logging in to gitlab.
Example DN:
CN=Test\, User,OU=Organization,DC=Company
CN=Test User,OU=Organization,DC=Company
http://www.ietf.org/rfc/rfc4514.txt