Loading `ApplicationSetting` from Redis was responsible for at least 50%
of the CPU load of the Redis cluster on GitLab.com. Since these values
generally don't change very much, we can load this from the database and
cache it in memory, skipping Redis altogther. We use
`ActiveSupport::Cache::MemoryStore` as a drop-in replacement for
`RedisCacheStore` even though we probably don't need synchronized access
within `Thread.current`.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63977

The circuit breaker itself got removed a while ago, when that happened
some parts got left behind. Using grep old stale settings and
validations were found and are now removed.

Storing this key in secrets.yml was a bad idea,
it would require users using HA setups to manually
replicate secrets across nodes during update,
it also needed support from omnibus package

* Revert "Generate Let's Encrypt private key"
  This reverts commit 444959bfa0b79e827a2a1a7a314acac19390f976.

* Add Let's Encrypt private key to settings
  as encrypted attribute

* Generate Let's Encrypt private key
  in database migration

Store Let's Encrypt account email in application settings
Also add explicit terms of service consent

- Update PO file

Fix ApplicationSetting development seed

Closes #60278

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

Renamed UrlValidator to AddressableUrlValidator to avoid 'url:' naming collision with ActiveModel::Validations::UrlValidator in 'validates' statement.
Make use of the options attribute of the parent class ActiveModel::EachValidator.
Add more options: allow_nil, allow_blank, message.
Renamed 'protocols' option to 'schemes' to match the option naming from UrlValidator.

It could happen that there's a cached (in Redis) ApplicationSetting
record, and calling
`Gitlab::CurrentSettings.current_application_settings` only returns it
instead of creating a new DB record, which makes the
`ApplicationSetting.current_without_cache.update!` call fail.

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