Return certain branches by default in the initial RefSelector list - such as the default branch and protected branches
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=428136)
</details>
<!--IssueSummary end-->
<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
### Proposal
A customer upgraded from 14.8 to 15.8 and [noticed differences in behaviour](https://gitlab.zendesk.com/agent/tickets/457650) (internal link) using the 'select Git revision' feature in project repositories.
I understand this uses RefSelector, and that this feature has been enhanced to support more use cases ([example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55245)) and various features have been migrated to it (example: [pipelines](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110046))
When selecting a branch from the default list, it's likely that certain branches are more likely to be selected than others. The default branch and protected branches, for example. Would it be possible to have these populated in the initial list returned?
The ticket I've linked above contains some feedback from folks using GitLab about the apparent random nature of branches in the list, vs. either previous behaviour of the product or their expectations that it would return a more logical selection of refs.
I'm wondering if we could seed that initial list differently, possibly much more cheaply, and improve UX at the same time:
- Classes of branch, such as the ones I've suggested (protected branches, default branch)
- These might be cached in Redis already to support other internal functionality?
- Populate the list on a per-user basis that makes a lot more sense for them personally.
- Do user profiles have any branch data that the product could use to derive this list?
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
issue