Double-checked internal ID generation for transition phase

What does this MR do?

This change adds "double-checking" for generation of internal ids for issues. That is, when using the AtomicInternalId module, we track the last internal id for issues. For a new issue, the internal id is incremented but (with this change) at the same time we calculate the maximum iid present for the project. If the latter is greater than the incremented value, we correct the value for InternalId.

This helps in a transition phase from NonatomicInternalId to AtomicInternalId, in particular when both old and new code is running at the same time (e.g. during a deploy).

I don't expect a performance issue here because calculating the maximum iid across a project is something we were doing all the time in the past (for each new issue). However, let's keep in mind that this is now done while keeping a lock on a InternalId record.

The follow-up issue to revert this change and remove the double-checking for 10.8 is https://gitlab.com/gitlab-org/gitlab-ce/issues/45389.

Why was this MR needed?

We ran into this problem during the deploy: https://gitlab.com/gitlab-com/infrastructure/issues/4019

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Tests added for this feature/bug
• Review
  • Has been reviewed by Backend
  • Has been reviewed by Database
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together
• End-to-end tests pass (package-and-qa manual pipeline job)

What are the relevant issue numbers?

Closes #45269 (closed)