Previously imports would fail if a merge request note included a
suggestion with an
`ActiveRecord::HasManyThroughCantAssociateThroughHasOneOrManyReflection`
exception.

This was happening because suggestions were listed as a descendant of
merge requests, but this doesn't work because suggestions are directly
associated with notes, not merge requests, and that association is lost.
Rails also disallows creating intializing a has_many association through
a different object.

We fix this by making `suggestions` a child of `notes` within a merge
request. This doesn't fix previously broken exported project exports,
but new exports will work.

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

- Added Importable to models/list.rb
- Did unless: :importable? on board validation
- Created changelog
- Modified haml to show issue boards are importable
- Added needed spec tests
- Modified project.json to include board information
- Added relevant models to all_models
- Added relevant models to import_export
- Added relevant models to safe_model_attributes

This backports all changes made to an import/export fixture file from EE
to CE.

https://community.atlassian.com/t5/Jira-questions/Is-it-quot-JIRA-quot-or-quot-Jira-quot/qaq-p/681163Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Ignore some columns

This reverts commit a5378665.

Fixes gitlab-org/gitlab-ce#42595

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.

When importing from a GitLab archive, an admin can carry over the
assignations. Other users can not.

When a regular user is importing an issue with multiple assignees, the
assignee is replaced with the current user, meaning we would try to
insert current user as an assignee multiple times.

By filtering the array before storing it, the import becomes more
robust.

This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.

This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.

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

The st_commits and st_diffs columns on merge_request_diffs historically held the
YAML-serialised data for a merge request diff, in a variety of formats.

Since 9.5, these have been migrated in the background to two new tables:
merge_request_diff_commits and merge_request_diff_files. That has the advantage
that we can actually query the data (for instance, to find out how many commits
we've stored), and that it can't be in a variety of formats, but must match the
new schema.

This is the final step of that journey, where we drop those columns and remove
all references to them. This is a breaking change to the importer, because we
can no longer import diffs created in the old format, and we cannot guarantee
the export will be in the new format unless it was generated after this commit.

This finishes the procedure for migrating events from the old format
into the new format. Code no longer uses the old setup and the database
tables used during the migration process are swapped, with the old table
being dropped.

While the database migration can be reversed this will 1) take a lot of
time as data has to be coped around 2) won't restore data in the
"events.data" column as we have no way of restoring this.

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

This is an ID-less table with just three columns: an association to the merge
request diff the commit belongs to, the relative order of the commit within the
merge request diff, and the commit SHA itself.

Previously we stored much more information about the commits, so that we could
display them even when they were deleted from the repo. Since 8.0, we ensure
that those commits are kept around for as long as the target repo itself is, so
we don't need to duplicate that data in the database.

This adds an ID-less table containing one row per file, per merge request
diff. It has a column for each attribute on Gitlab::Git::Diff that is serialised
currently, with the advantage that we can easily query the attributes of this
new table.

It does not migrate existing data, so we have fallback code when the legacy
st_diffs column is present instead. For a merge request diff to be valid, it
should have at most one of:

* Rows in this new table, with the correct merge_request_diff_id.
* A non-NULL st_diffs column.

It may have neither, if the diff is empty.