In GitLab 12.3.7, a number of fields were encrypted with
attr_encrypted. Unfortunately, `FakeApplicationSetting` doesn't
implement the `attr_encrypted` fields, so any encrypted value stored in
the database would be empty while pending migrations exist.

Originally `FakeApplicationSetting` existed when mixed versions of
GitLab in a no-downtime deployment used the same Redis key, causing new
attributes to be present when they were not known by older
deployments. `FakeApplicationSetting` is really only needed in a Rake
task where certain application settings may be expected to be available
but haven't been applied via a migration. Since the cache key is now
based on the GitLab and Rails version, this should no longer be an
issue.

We restrict the use of `FakeApplicationSetting` to Rake tasks. Web and
Sidekiq workers should always have a real `ApplicationSetting` object.

Closes https://gitlab.com/gitlab-org/gitlab/issues/197988