Fix a race condition in the shard population logic

What does this MR do?

When multiple GitLab processes start up at the same time, they all try to create a list of shards in the database simultaneously. Sometimes, this can race - two processes will try to add the same shard at the same time.

The introducing MR was meant to handle this, but I missed that the failing INSERT SQL command invalidated any surrounding transaction - and such a transaction existed. On retry, this caused the "duplicate key" error we rescue from to be promoted into an "invalid transaction" error, which we don't rescue from.

This MR removes the - overly paranoid - transaction, allowing the existing retry logic to operate correctly.

Unfortunately, this is quite hard to test, since we're using ActiveRecord's find_or_create_by method, which contains deep magic.

What are the relevant issue numbers?

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• Tests added for this feature/bug
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.

Closes #53972 (closed)