Create Branch based on upstream project using web interface when working on a fork

Problem/User Story

For a user who is using the GitLab web interface entirely (so no local git on their machine), the workflow of forking a project and submitting pull requests works well the first time, since the moment a user creates a fork of a project, their fork is up-to-date with the upstream project (i.e. fork:master and upstream:master are on the same commit).

If the contributing user then uses the Web IDE to start creating a branch to be submitted as a merge request, the Web IDE has a drop-down to pick which branch to work off of, but it only has branches for the current project. So, the user can select their fork:master branch, and work from there, and submit the merge request just fine.

But an issue arises if the upstream project moves along in development and the contributing user wants to make another edit. Now their fork:master is behind upstream:master, so creating a new patch branch off of fork:master will be missing changes or have merge conflicts with upstream. There is a "mirror" option to have the fork project periodically sync with the upstream project, but that requires entering the username and password into it (which means remembering to update it whenever a user's password changes, which might be fairly frequent in an enterprise/internal instance), or use SSH keys (which may be disabled in an enterprise/internal instance).

Alternatively, there seems to almost be a solution using the Web IDE interface in a different way. If visiting a project that the user does not have any rights to push to, and the user does not have a current fork of the project, that user does not see the Web IDE button when browsing the upstream project. However, if the user does fork the project and then returns to the upstream project, they do see the Web IDE button there. When using the Web IDE in this way, the branch-selecting dropdown shows branch names from the upstream project, not from the fork. However, when that user tries to submit their changes by making a new branch, the action fails with an error banner.

Proposed Solution

Instead of needing to deal with mirroring options when the project being worked on is a fork of another project on the same GitLab instance, all the means of creating a new branch in a project (The Repository > Branches > "New Branch" form, and the Web IDE branch-selection drop-down) should include not only the local repository's branches, but the upstream project's branches too.

In that way, even if the forked project's master branch never gets fast-forwarded to where the upstream master is, being able to create branches off of the upstream:master commit would make infrequent, minor updates much easier to accomplish entirely within the GitLab web interface.

Or, update the "mirroring" feature to detect if the target repository is in the same GitLab instance, and then not require separate authentication to link them (such that the mirror continues to work through a user password change), or create a separate "mirror" option for projects that are forks, to periodically update branches from their upstream project.

Or, using the alternative workflow: If a user who has a fork of a project navigates to the parent/upstream project and enters the Web IDE of that project, when they have finished their edits and wish to create a new branch to commit them, the new branch should be created on their fork of the project (not attempting to create it on the parent/upstream project that they don't have rights to).

Partly-related issue: #24397 (closed)