Checking for each epic validatiy in
Issues::ExportCsvService is no longer needed
after migration that deleted invalida records.
Given it is an expensive check, we need to remove
it

Changelog: fixed
EE: true

- Removes the validation checks from services and
adds a validation to the model instead
- Modify the epic_issues factory to create
valid associations
- Fix specs with invalid records

Changelog: added
EE: true

Nullify parent epic when moving an issue
to a different group hierarchy

Changelog: security
EE: true

The plan for RSpec 4.0 is to disable monkey patching:
https://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero-monkey-patching-mode

This commit stops using RSpec monkey patching:
https://relishapp.com/rspec/rspec-core/docs/configuration/zero-monkey-patching-mode

Export issues feature is being open sourced
because we allow importing on core but not export.

We want to be able to export issues and then use that export file to
import the issues to another GitLab project.

Prior to this change, the format of the export file did not match the
structure of the file that the issue importer expects. This change
expands the importer to first look for the know export column names and
then fallback to positional values if they are not present.

Addresses:
- https://gitlab.com/gitlab-org/gitlab/issues/199038
- https://gitlab.com/gitlab-org/gitlab/issues/30931

- only include when the epics feature is available

https://gitlab.com/gitlab-org/gitlab/issues/27703

Move creation of time logs before the update of the issue in the
setup. The introduction of `touch: true` in gitlab-org/gitlab-ce!19065
causes the timestamp to be updated.

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

If issues are filtered by multiple labels, then GROUP BY statement
is used to filter only issues with these labels. This is problem in
combination with '.includes' which may use JOIN statement to load
associated resources in single query instead of a separate query.

Then the generated SQL query fails because associated resources
are included in 'SELECT ...' statements but not in the GROUP BY
statement.

Usage of '.preload' instead of '.includes' ensures that Active Record
uses a separate query instead of JOIN.

Closes #4376

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

Having two states that essentially mean the same thing is very much like
having a boolean "true" and boolean "mostly-true": it's rather silly.
This commit merges the "reopened" state into the "opened" state while
taking care of system notes still showing messages along the lines of
"Alice reopened this issue".

A big benefit from having only two states (opened and closed) is that
indexing and querying becomes simpler and more performant. For example,
to get all the opened queries we no longer have to query both states:

    SELECT *
    FROM issues
    WHERE project_id = 2
    AND state IN ('opened', 'reopened');

Instead we can query a single state directly, which can be much faster:

    SELECT *
    FROM issues
    WHERE project_id = 2
    AND state = 'opened';

Further, only having two states makes indexing easier as we will only
ever filter (and thus scan an index) using a single value. Partial
indexes could help but aren't supported on MySQL, complicating the
development process and not being helpful for MySQL.

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