There are two major reasons for this:

1. We made a mistake in the algorithm when recalculating this for the
first time.
See: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67578

2. The algorithm changed yet again to improve the tracking method
See: https://gitlab.com/gitlab-org/gitlab/-/issues/322044

Changes:

* Update background migration to use signatures

* Make previous reschedule a no-op so customers doing major version
  leaps will not schedule the same job multiple times

* Remove ALL jobs from `background_migration_jobs` table. Succeeded jobs
  should be removed anyway and pending jobs were not finished because we
  had records for which the recalculation yielded identical UUIDv5. The
  reason we had such records was due to mistake outlined in point 1.
  This situation was fixed by
  https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74008

* Schedule `RecalculateVulnerabilitiesOccurrencesUuid` over entire
  `vulnerability_occurrences` table so we can leverage our new algorithm
  and finish the migration path from UUIDv4 to UUIDv5.

Changelog: added