A user can become ldap_blocked during an ldap outage and not restored to unblocked on recovery

I'll include a summary from comments here:

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2242#note_3958062

I hit an issue with this in 8.4.3 - some users became ldap_blocked and I couldn't reset their state. I think there was a temporary connection failure to the ldap server and they could not be authenticated. I wonder if this made them ldap_blocked? Once the connection was restored they could not re-authenticate (possibly due to being blocked) and did not become unblocked. To fix I manually changed their state to "active" in the users db table.

@adaijiushiwo saw the same problem

@cbartz suggested a potential problem in lib/gitlab/user_access.rb :

def self.allowed?(user)

@dblessing said The first conditional/guard checks for manual admin blocks. These should not be overridden by LDAP. Only LDAP blocks (ldap_blocked) should be set/removed automatically.

I think @cbartz may be right as in app/models/user.rb I see:

    state_machine :state, initial: :active do
      event :block do
        transition active: :blocked
        transition ldap_blocked: :blocked
      end
    
      event :ldap_block do
        transition active: :ldap_blocked
      end
    
      event :activate do
        transition blocked: :active
        transition ldap_blocked: :active
      end
    
      state :blocked, :ldap_blocked do
        def blocked?
          true
        end
      end
    end

Which seems to return true for blocked? for both :blocked and :ldap_blocked states. I'm not fully familiar with the idoms involved though