After the import has finished, we flush (delete) the InternalId records
related to the project at hand. This means we're starting over with
tracking correct internal id values, a new record will be created
automatically when the next internal id is generated.
The GitHub importer assigns iid values by using supplied values from
GitHub. We skip tracking internal id values during the import in favor
of higher concurrency. Deleting any InternalId records after the import
has finished is an extra measure to guarantee consistency.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54270.
This is useful for a transition period to migrate away from
`NoninternalAtomicId`. In a situation where both the old and new code to
generate a iid value is run at the same time (for example, during a
deploy different nodes may serve both versions), this will lead to
problems regarding the correct `last_value`. That is, what we track in
`InternalId` may get out of sync with the maximum iid present for
issues.
With this change, we double-check that and correct the `last_value` with
the maximum iid found in issues if necessary.
This is subject to be removed with the 10.8 release and tracked over
here: https://gitlab.com/gitlab-org/gitlab-ce/issues/45389Closes#45269.