Only read rebase status from the model
What does this MR do?
Prior to 12.1, rebase status was looked up directly from Gitaly. In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB column was added to track the status instead. However, we couldn't stop looking at the gitaly status immediately, since some rebases may been running across the upgrade.
Now that we're in 12.3, it is safe to remove the direct-to-gitaly lookup. This also happens to fix a 500 error that is seen when viewing an MR for a fork where the source project has been removed.
We still look at the Gitaly status in the service, just in case Gitaly and Sidekiq get out of sync - I assume this is possible, and it's a relatively cheap check.
Since we atomically check and set merge_requests.rebase_jid, we
should never enqueue two RebaseWorker jobs in parallel.
Does this MR meet the acceptance criteria?
Conformity
- [-] Changelog entry for user-facing changes, or community contribution. Check the link for other scenarios.
- [-] Documentation created/updated or follow-up review issue created
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
-
Separation of EE specific content
Performance and Testing
Related to #65797 (closed)