remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.

Adds Rubocop rule for line break after guard clause

Closes #18040

See merge request gitlab-org/gitlab-ce!15188

add_column_with_default is implemented in terms of update_column_in_batches, but
update_column_in_batches can be used independently. Neither of these should be
used on the specified large tables, because they will cause issues on large
instances like GitLab.com.

This also ignores the cop for all existing migrations, renaming
AddColumnWithDefaultToLargeTable where appropriate.

Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.

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

Replaces all the explicit include metadata syntax in the specs (tag:
true) into the implicit one (:tag).
Added a cop to prevent future errors and handle autocorrection.

These indexes are not recorded in the WAL (at least until PostgreSQL
10) and this isn't worth the minor performance improvement over btree
indexes.

This module provides a class method called `each_batch` that can be used
to iterate tables in batches in a more efficient way compared to Rails'
`in_batches` method. This commit also includes a RuboCop cop to
blacklist the use of `in_batches` in favour of this new method.

This cop has been renamed to ActiveRecordSerialize to match the way
"ActiveRecord" is usually written.