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
This fixes an issue where the user_id is not included in the data for
user_add_to_team and user_remove_from_team system hooks. The documentation
already states that the user_id should be included.
Ci Project migrate
- This doesn't migrate: allow_git_fetch, coverage_regex, timeout. Since this are project configuration settings I would propose to migrate them to `.gitlab-ci.yml`.
- This requires offline migrations.
- It simplifies database models making all CI objects to be attached to: Project.
- It removes Ci::Project, but makes /ci/projects working by adding method: Project.find_by_ci_id for backward compatibility (badges, triggers).
- We should add default `timeout` to Application Settings.
- It misses specs.
- It is based on ci-services-migrate for now.
- It removes CI events.
- It removes administrator CI projects overview.
- It removes CI application settings.
In 8.4 or 8.5 we can remove redundant tables and columns.
See merge request !1987