Fix the annotation migration for mysql

[FloThinksPi]

Slack Conversation: https://cloudfoundry.slack.com/archives/C07C04W4Q/p1704495655161239

Some mysql like DBs apearently do not support locking tables. An example for this is Percona xtraDB Cluster. With this change we optimistically try to run this migration consitently if we can. If not we try it anyway best effort.

The migration removes possible duplcates and then sets a unique constraint to prevent new duplicates. For this whole process to work consistently we need table locks to prevent inserts of new duplicates while the deduplication runs. Otherwise the creation of the unique
constraint may fail.

In case the table lock feature is not supported or the mysql db user is lacking permissions we deduplicate anyway and in case a error to set the unique constraint occurs we fail and rely on retry mechanism of db migrations to eventually succede the migration when the next run is not triggering the race condition described above that causes the migration to fail.

For Databases that support table locking this race condition cannot happen at all since writes to the table in question are prevented.

[sethboyles]

@FloThinksPi we've disabled rubocop for the offending errors logs so we can merge this and get pipelines green again. Not sure if we should be concerned about the output to stdout Rubocop--I think those logs will just go to the pre-start.stdout file (maybe we want stderr?)