Backfill LfsObjectsProject records of forks

What does this MR do?

To fix the behavior of existing forks, LfsObjectsProject records need to be backfilled. This is so we can remove the need to depend on the source when looking for LFS objects from forks.

Migration

Output:

== 20200210062432 ScheduleLinkLfsObjects: migrating ===========================
== 20200210062432 ScheduleLinkLfsObjects: migrated (0.0237s) ==================

Query Plans

• Total number of forks to be migrated (https://explain.depesz.com/s/BDUU): 14,094 (15 jobs for batch size of 1k)
• Per batch query plan (https://explain.depesz.com/s/v6ko, query): ~520ms (7.8 seconds for 15 batches)
• Insert query plan per batch (https://explain.depesz.com/s/N1wZ, query): ~13ms

Given the data above, there'll be 15 jobs that'll be enqueued that will be performed 2 minutes (this is the default interval we have) apart. That means the migration can be done in ~30 mins.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

#55487 (closed)