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

Because this could potentially load a model and we shouldn't
load models before all the patches we have in places.

Updates specs to use new rails5 format.

The old format:
`get :show, { some: params }, { some: headers }`

The new format:
`get :show, params: { some: params }, headers: { some: headers }`

This reverts commit 3560b11922fd180eea5cafd0e763e0e601c5c4ee.

This changes `correlation_id` to be `correlation-id` when passed via jobs

The Correlation ID is taken or generated from received X-Request-ID.
Then it is being passed to all executed services (sidekiq workers
or gitaly calls).

The Correlation ID is logged in all structured logs as `correlation_id`.

If the EncryptColumns background migration runs in a sidekiq with a
stale view of the database schema, or when the purported destination
columns don't actually exist, data loss can result. Attempt to work
around these issues by reloading schema information before running
the migration, and raising errors if the model reports that any of its
source or destination columns are missing.