GitLab

For the sake of consistency, removes any extraneous
consecutive blank lines from the doc suite.

Pool repositories are persisted in the database, and when the DB is
restored, the data need to be restored on disk. This is done by
resetting the state machine and rescheduling the object pool creation.

This is not an exact replica of the state like at the time of the
creation of the backup. However, the data is consistent again.

Dumping isn't required as internally GitLab uses git bundles which
bundle all refs and include all objects in the bundle that they require,
reduplicating as more repositories get backed up. This does require more
data to be stored.

Fixes https://gitlab.com/gitlab-org/gitaly/issues/1355

- Rearrange sections
- Stress out the importance of storing config files
- Add troubleshooting guide in case secrets is lost

Fast lookup of authorized SSH keys in the database was ported to CE in
v10.4. This change adds the option to enable the setting via the restore
rake task and assumes yes if the force env variable is set.

Sentence language seemed to contradict the section header, so it's
been clarified to prevent any confusion. Also added information
about how wikis are handled during a backup.

Originally submitted at
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6673

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

Closes #38949

Using a mountpoint as data directory causes issues when restoring, so
we need to mention this in the documentation.

See https://github.com/fog/fog-aws/issues/428#issuecomment-360869183

Closes gitlab-org/gitlab-ee#4419

https://gitlab.com/gitlab-org/gitlab-ce/commit/7f8ef19c411eceec207fef5d8459fbeaa40bf464 most likely broke the old configuration format where empty string aws_access_key_id & aws_secret_access_key were still OK. From 9.5 onwards moving backups to S3 using IAM profiles will fail if they are configured.

The new description will make it more clear that
there are 3 separate things being affected and not
just 2FA.

[skip ci]

[skip ci]