Fork interface with "Prevent forking outside a group" is extremely slow

Summary

GitLab.COM (and any nightly build of gitlab after 2020-08-04 / a4dfe1f2) now has the option to prevent forking outside a group, and a revised list-like project-forking interface.

With "Prevent forking outside of the group" enabled, the time to display all possible fork locations has increased 4-5x versus 13.2's interface.

This performance regression is so severe as to have completely broken the forking feature for this customer.

Steps to reproduce

I created the attached screengrabs by deploying a docker-based gitlab/gitlab-ee:nightly instance and creating ~2000 empty groups under a top-level group, and a project with a single file.

Example Project

• https://staging.gitlab.com/jrreid-forking-test group on staging. with 2001 sub-groups
• https://staging.gitlab.com/jrreid-forking-test/first-level-subgroup/test-project/-/forks/new public project within the top-level group that is slow to fork

Screencaps

Showing 13.2 (Screen_Recording_2020-08-12_at_1.52.01_PM) vs 13.3.pre (nightly_fork.mp4) performance:

• nightly_fork
• Screen_Recording_2020-08-12_at_1.52.01_PM

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise.)

Output of checks

This bug happens on GitLab.com and on any self-managed instance >13.3

Possible fixes

Perhaps we should consider progressively loading available subgroups for fork locations on a page-by-page basis rather than all-up-front.