* Add email_header_and_footer_enabled flag to appearances table
* Set email_header_and_footer_enabled default value to false
* Add checkbox to appearance to toggle show header and footer in emails
* Add email_header_and_footer_enabled to allowed params in controller
* Add header and footer messages to the html and text email layouts
* Remove the color styling for emails header and footer
* Add empty_mailer layout for emails without layout,
to have the header and footer applied

remove EE specific code
remove EE licence checks
move migration from EE to CE folder structure
move specs from EE to CE folder structure
remove EE specific flag specs

Prior to GitLab 9.0, attachments were not tracked the `uploads` table,
so it was possible that the appearance logos were just stored in the
database as a string and mounted via CarrierWave.

https://gitlab.com/gitlab-org/gitlab-ce/issues/29240 implemented in
GitLab 10.3 was supposed to cover populating the `uploads` table for all
attachments, including all the logos from appearances. However, it's
possible that didn't work for logos or the `uploads` entry was orphaned.

GitLab instances that had a customized logo with no associated `uploads`
entry would see Error 500s. The only way to fix this is to delete the
`logo` column from the `appearances` table and re-upload the attachment.

This change makes things more robust by falling back to the original
behavior if the upload is not available.

This is a CE backport of
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9277.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/9357

When object storage is enabled, the logos used to customize a GitLab
appearance causes the time-limited URLs to be used. We fix this
by forcing all of these URLs to use the /uploads/-/system prefix
so that they will always be proxied through GitLab.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/6778

Partially addresses #47424.

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

ObjectStore uploader requires presence of associated `uploads` record
when deleting the upload file (through the carrierwave's after_commit
hook) because we keep info whether file is LOCAL or REMOTE in `upload`
object.

For this reason we can not destroy uploads as "dependent: :destroy" hook
because these would be deleted too soon. Instead we rely on
carrierwave's hook to destroy `uploads` in after_commit hook.

But in before_destroy hook we still have to delete not-mounted uploads
(which don't use carrierwave's destroy hook). This has to be done in
before_Destroy instead of after_commit because `FileUpload` requires
existence of model's object on destroy action.

This is not ideal state of things, in a next step we should investigate
how to unify model dependencies so we can use same workflow for all
uploads.

Related to #45425