GitLab

DB schema generated by a migration may look different in
rails 4 and 5 (because rails 5 may use different default values).
For this reason it's important to explicitly set for which rails
version a migration was written for.

See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912

1. Rescue all errors that `Projects::DestroyService` might throw, to prevent the
   worker from leaving things in an inconsistent state

2. Unmark the project as `pending_delete`

3. Add a `delete_error` text column to `projects`, and save the error message in
   there, to be shown to the project masters/owners.

These new checks can be used to check if migrations require downtime or
not (as tagged by their authors). In CI this compares the current branch
with master so migrations added by merge requests are automatically
verified.

To check the migrations added since a Git reference simply run:

    bundle exec rake gitlab:db:downtime_check[GIT_REF]

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

Since we eager load everything in lib/ putting ERB code in .rb files
will result in syntax errors. By moving the templates to
./generator_templates we can work around this.

This allows us to automatically include
Gitlab::Database::MigrationHelpers into newly generated migrations.