Give CI_JOB_TOKEN permission to access public packages

🔭 Context

Users can consume packages from the GitLab package registry in their CI pipelines. Packages belong to projects. It is common for users to authenticate using a CI_JOB_TOKEN when working in CI jobs.

Currently, if a user consumes/installs a package from a public project in a pipeline for a different project, the package is successfully installed because the request is anonymous, and the code will check Ability.allowed?(nil, :read_package, public_project) and Ability.allowed?(nil, :read_project, public_project). Anonymous users have both :read_package and :read_project permissions for public projects, so both will return true and the CI job will succeed.

However, if a job is authenticated using the CI_JOB_TOKEN, the code will check Ability.allowed?(ci_job_token, :build_read_project, public_project), which will return false, and despite being a public project, the package installation will fail.

So why are we checking :build_read_project instead of :read_project (which will return true for the ci_job_token)?

In the find_project! helper, when dealing with CI job token authentication, we try to limit the permissions of the job user. This happens here: https://gitlab.com/gitlab-org/gitlab/-/blob/572bb8c0fe055eb32030a8b48764113d8fe2aa6f/ee/lib/ee/api/helpers.rb#L93. You can see that when a user is present, we check :read_project, but when a CI_JOB_TOKEN is present, we check :build_read_project.

🔬 What does this MR do?

Updates the permissions to also allow :build_read_project for public projects.

Screenshots (strongly suggested)

☑ Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • [-] I have not included a changelog entry because _____.
• [-] 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

Related to #213723 (closed)