- Refactor uploads manager
- Refactor importer, update import spec
- Add more object storage specs

Enables frozen string for new files in
directories that had been previously
covered in previous MR's.

Partially addresses #47424.

Previously we would pull the file, now, we just stream-it as needed from Object Storage

Partially addresses #47424.

See https://gitlab.com/gitlab-org/gitlab-ce/issues/47677 for more information

For FileUploaders it's possible that a model has many uploads
and if lease key is created only from model id, it causes that
the model's uploads can not be migrated in parallel because the
exclusive lease key would be same for all uploads of the model.

the related omnibus graphicsmagick package only supports those formats.

see https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1975

the initial reason for this change was that graphicsmagick does not
support writing to ico files. this fact lead to a chain of changes:

1. use png instead of ico (browser support is good enough)
2. render the overlays on the client using the canvas API. this way we
   only need to store the original favion and generate the overlay versions
   dynamically.
   this change also enables (next step) to simplify the handling of the
   stock favicons as well, as we don't need to generate all the versions
   upfront.

this ways we can keep the `lib/gitlab/ci/status/*` classes to return the
bare favicon name as it was before.

also the favicon uploader versions are now have the same names as the
stock favicons (+ `favicon_` prefix), which makes working with the
status names easier.

when versions have a different file format from the original file
carrierwave constructs a wrong url (with the original file suffix).

This is tricky: the query was being run in
`ObjectStorage::Extension::RecordsUploads#retrieve_from_store!`, but we can't
just add batch loading there, because the `#upload=` method there would use the
result immediately, making the batch only have one item.

Instead, we can pre-emptively add an item to the batch whenever an avatarable
object is initialized, and then reuse that batch item in
`#retrieve_from_store!`. However, this also has problems:

1. There is a lot of logic in `Avatarable#retrieve_upload_from_batch`.
2. Some of that logic constructs a 'fake' model for the batch key. This should
   be fine, because of ActiveRecord's override of `#==`, but it relies on that
   staying the same.

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

Old records have a null value of file_store column.
This causes the problems with current direct_upload implementation,
as this makes it to choose Store::REMOTE instead of Store::LOCAL.

This change moves the store save when change saving the object.

Previously we scheduled a worker to just some this but we were running
into performance issues when the build table was getting too large. So
now we've updated the code such that this column is updated immediately
and incremented/decremented by the correct amount whenever artifacts are
created or deleted.

We've also added the performance optimization that we do not update this
statistic if a project is deleted because it could result in many
updates for a project with many builds.