For 4 years we've had logic in our database migrations that required you
to set a constant `DOWNTIME = true` if you required downtime and seek
approval from the VP of Engineering. We have never once used this
process as we've always found a way around the problem using a different
approach.

As such we decided in
https://gitlab.com/gitlab-org/gitlab/-/issues/326495 that we should just
remove this `DOWNTIME` constant and the extra checks here to reduce
noise in our database code review and give less processes for people to
learn.

This MR removes a lot of things and here is a high level summary:

1. Remove DowntimeCheck class and the rake task that invoked and the CI
job that invoked that rake task and any related tests, helper classes
2. Update documentation to make it clearer that downtime is not allowed
and therefore remove the approval process
3. Update a page called `what_requires_downtime` to be called
`avoiding_downtime_in_migrations` since it was already a set of patterns
to avoid downtime and now it's worded more strongly to imply that we can
always get away without downtime
4. Various other docs pages that had examples of migrations that used
the `DOWNTIME` constant
5. Various rubocop specs that had migrations in them which used the
`DOWNTIME` constant

The one thing I did not do is go back and remove `DOWNTIME = false` from
all the existing migrations. In general we should not be updating
migrations once they've run and this would have made this MR change many
thousands of files so it's not worth it.