This sets up all the basics for importing Phabricator tasks into
GitLab issues.
To import all tasks from a Phabricator instance into GitLab, we'll
import all of them into a new project that will have its repository
disabled.
The import is hooked into a regular ProjectImport setup, but similar
to the GitHub parallel importer takes care of all the imports itself.
In this iteration, we're importing each page of tasks in a separate
sidekiq job.
The first thing we do when requesting a new page of tasks is schedule
the next page to be imported. But to avoid deadlocks, we only allow a
single job per worker type to run at the same time.
For now we're only importing basic Issue information, this should be
extended to richer information.
If for whatever reason we fail to import MR data,
subsequent run will fail as we try to insert duplicate data.
Instead of trying to recover, lets delete all and retry again.
The SQL queries and memory allocation in MergeRequests::RefreshService
is dominated by queries for Project and Route loads. On staging, the
absence of an inverse relationship caused Rails to make over 1100
extraneous SQL queries for the www-gitlab-com repository.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/49703
Just like with the GitHub importer, the Bitbucket Server importer can hit the
default 60 s idle-in-transaction timeouts if it takes too long to create the
merge request. We solve this by using the same approach as the GitHub importer:
1. Bypass all validation and hooks in creating a merge request
2. Insert the Git data in a separate transaction
Part of #50021
