This resolves an "ArgumentError: comparison of String with 0 failed"
issue where the visibility_level is stored as a string in the project
import data because the value comes directly from the Web form. This
problem happened upon creating a project from a template or restoring a
project.

We now cast the value to an integer to guard against these kinds of
failures.

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

Enables frozen string for the following:

* lib/gitlab/hook_data/**/*.rb
* lib/gitlab/i18n/**/*.rb
* lib/gitlab/import/**/*.rb
* lib/gitlab/import_export/**/*.rb
* lib/gitlab/kubernetes/**/*.rb
* lib/gitlab/legacy_github_import/**/*.rb
* lib/gitlab/manifest_import/**/*.rb
* lib/gitlab/metrics/**/*.rb
* lib/gitlab/middleware/**/*.rb

Partially addresses gitlab-org/gitlab-ce#47424.

Updated docs, refactor import/export code
Fix AvatarUploader path issue
Fix project export upload webhook error

Changes update_column to update_attributes in ProjectTreeRestorer#restore_project by using timeless to maintain the current timestamps

Since we can regenerate `description_html` from the `description`, we
should not export it. This avoids some complexity when overriding the
description during an import/export where we would need to invalidate
this cached field.

Now we refresh the markdown cache after the import

This overrides values defined in the project JSON with the values
provided in project.import_data.data['override_params'].

These could be passed from the API.

and fixes the project description not being imported

Compared to the merge_request_diff association:

1. It's simpler to query. The query uses a foreign key to the
   merge_request_diffs table, so no ordering is necessary.
2. It's faster for preloading. The merge_request_diff association has to load
   every diff for the MRs in the set, then discard all but the most recent for
   each. This association means that Rails can just query for N diffs from N
   MRs.
3. It's more complicated to update. This is a bidirectional foreign key, so we
   need to update two tables when adding a diff record. This also means we need
   to handle this as a special case when importing a GitLab project.

There is some juggling with this association in the merge request model:

* `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
* `MergeRequest#merge_request_diff` reuses
  `MergeRequest#latest_merge_request_diff` unless:
    * Arguments are passed. These are typically to force-reload the association.
    * It doesn't exist. That means we might be trying to implicitly create a
      diff. This only seems to happen in specs.
    * The association is already loaded. This is important for the reasons
      explained in the comment, which I'll reiterate here: if we a) load a
      non-latest diff, then b) get its `merge_request`, then c) get that MR's
      `merge_request_diff`, we should get the diff we loaded in c), even though
      that's not the latest diff.

Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
but not quite all.

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

Fix symlink vulnerability in Import/Export

Replaces https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2018 made by @james

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23822

See merge request !2022
Signed-off-by: NRémy Coutable <remy@rymai.me>