Propagate LFS record entries to forks upon push

What does this MR do and why?

When using LFS in combination with a fork based workflow all newly added LFS data must be downloaded and uploaded again by the developer who wants to rebase his fork. This is in fact not needed if the fork lives in the same gitlab instance as the source project. Essentially, this patch replicates the database entries (LFS records) towards forks after a push to the upstream project.

Moreover, this patch should solve other tickets as well, e.g #297022 (closed), #271576 (closed).

How to set up and validate locally

Problem description:

1. Create a upstream project containing LFS data
2. Fork from this project. Both projects can be cloned and checked out successfully
3. Add a new or adjust one or more LFS files in the upstream project
4. Try to rebase the local branches from a stand alone forked checkout onto the new upstream commits and push to fork. This does not work because the LFS data are not listed as records at the fork! The user must download first all LFS data from the whole history just to be able to push them again.

Solution:

1. Enable the feature flag lfs_propagate_forks:

   Feature.enable(:lfs_propagate_forks)

2. Repeat 1 through 4 from above
3. Checkout and push works via fork only!

MR acceptance checklist

• I have evaluated the MR acceptance checklist for this MR.

TODO

• Documentation