Tracking database integrity issue on gprd caused by bad database migration

https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4719 , which has (I believe) been run on gprd, has a bug: https://gitlab.com/gitlab-org/gitlab-ee/issues/5646

This means that the job_artifact_registry_table on gprd is unreliable and should be emptied.

Unfortunately, we have a post-migration: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/ee/db/geo/post_migrate/20180331055706_delete_job_artifacts_from_file_registry.rb which has, I suspect, already removed all the mirroring rows from the file_registry table. So we effectively have to rebuild the job_artifact_registry table again from scratch.

If it hasn't run for some reason, we can mark it NOT TO RUN, then just run the down migration for 20180322062741 now and re-run the up migration for the next RC that fixes the bug.

The bad migration was introduced in v10.7 and hasn't made it to a non-RC release yet, so hopefully none of our customers have been affected by it.

This is just tracking information and artifacts are idempotent, so it shouldn't be a problem if we have to regenerate the data from scratch. At worst, we end up with some files on disk that shouldn't be there (as the traces are being migrated to object storage).