Older namespace records may be both `type == ‘Group` AND `owner_id` is not null.

Not assigning the trackable fields seems to cause strange side-effects.

Every time a user logs in or out, the Trackable attributes are written to the
database. This is causing a lot of load on the database, for data that isn't
really critical.

So to avoid the database being hammered, add a Gitlab::ExclusiveLease before
writing trackable attributes to the database. This lease expires after an hour,
so only when the attributes were written more than an hour ago, they can be
written again. Otherwise they are ignored.

On databases such as MySQL, it's possible to get into a timing comparison
error if the value of `Confirmable#confirmation_sent_at` is within a second
of `0.days.ago`. This is possible mostly in specs that test this behavior
and most likely not happening in practice. The result of this error causes
a user to be deemed active when it should be inactive. To prevent this
error, we explicitly check the configuration setting to be `0.days.ago`.

Closes gitlab-org/gitlab-ee#2362

This reflects better that it validates paths instead of a namespace model

CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/962

Refactored specs and added a post deployment migration to remove the activity users table.

It uses a user activity table instead of a column in users.
Tested with mySQL and postgreSQL

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep
   things explicit. Specs testing the behavior of this class are moved into a
   separate service spec file.

2. Add a `user.reported_abuse_reports` association to make the
   `migrate_abuse_reports` method more consistent with the other `migrate_`
   methods.

Introduction
------------

1. The foreign key was not explicitly specified on the association.
2. The `AbuseReport` model contains two references to user - `reporter_id` and
   `user_id`
3. `user.abuse_report` is supposed to return the single abuse report where
   `user_id` refers to the given user.

Bug Description
---------------

1. `user.abuse_report` would return an abuse report where `reporter_id` referred
   to the current user, if such an abuse report was present.

2. This implies a slightly more serious bug as well:

   - Assume User A filed an abuse report against User B
   - We have an abuse report where `reporter_id` is User A and `user_id` is User B
   - If User A is updated (`user_a.block`, for example), the abuse report would
     also be updated, such that both `reporter_id` _and_ `user_id` point to User A.

Fix
---

Explicitly declare the foreign key `user_id` in the `has_one` declaration

Signed-off-by: Rémy Coutable <remy@rymai.me>