Avoid unnecessary locks on internal_ids

What does this MR do?

This avoid an unnecessary FOR UPDATE lock on internal id records when the iid value has been generated internally anyways.

The lock is still required to track any values that come in through other means, i.e. set by a user (through the API).

This targets the situation we have in CI. We purposefully generate the IID outside of a (long) transaction before creating the actual record:

https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fci%2Fpipeline%2Fchain%2Fpopulate.rb#L14

pipeline.ensure_project_iid!
# kick of long transaction that ultimately creates (inserts) the pipeline

In this case, we don't want the long transaction to do any locking anymore and we don't need to since the iid has been generated earlier by the normal means anyways.

Statistics for the amount of unnecessary locks can be found in #30515 (comment 221871147).

The broader picture is in #30515 (closed)

Performance and Testing

By default, the feature flag iid_always_track is enabled - which does not change behavior. Once disabled, the new behavior is used. This is so we can flip it off on GitLab.com after deployment, verify it's doing the right thing before releasing it and removing the flag.