This reverts merge request !20679

if all methods are also presented in the user.

Enable frozen string in:

* app/presenters
* app/policies

Partially addresses #47424.

This makes it more explicit that an environment is not a stop action,
but instead is merely contains a stop action.

This allows us to check specific abilities in views, while still
enabling/disabling them at once.

Operations and Kubernetes items are now omitted in the sidebar when repository or builds are disabled

"Maintainer" will be freed to be used for #42751

The `access_git` and `access_api` were currently never checked for
anonymous users. And they would also be allowed access:

  An anonymous user can clone and pull from a public repo

  An anonymous user can request public information from the API

So the policy didn't actually reflect what we were enforcing.

When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.

This enforces the terms in the web application. These cases are
specced:

- Logging in: When terms are enforced, and a user logs in that has not
  accepted the terms, they are presented with the screen. They get
  directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
  with the screen to accept the terms. After they accept they are
  directed to the dashboard.
- While a session is active:
  - For a GET: The user will be directed to the terms page first,
    after they accept the terms, they will be directed to the page
    they were going to
  - For any other request: They are directed to the terms, after they
    accept the terms, they are directed back to the page they came
    from to retry the request. Any information entered would be
    persisted in localstorage and available on the page.

When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.

We will reuse the the dropdown, but exclude some menu items based on
permissions.

So moving the menu to a partial, and adding checks for each menu item here.

This prevents performing the requests, and disables all emoji reaction buttons

So we can distinguish between the permissions on the source and the
target project.

- `create_merge_request_from` indicates a user can create a merge
  request with the project as a source_project
- `create_merge_request_in` indicates a user can create a merge
  request with the project as a target_project

This prevents creating merge requests targeting archived projects.

This could happen when a project was already forked, but then the
source was archived.

That way the ProjectPolicy class can be extended with this module
before we prepend the EE::ProjectPolicy. This makes the classmethods
available for rules defined in the EE::ProjectPolicy.

Rename delete_protected_branch ability to push_to_delete_protected_branch to prevent confusion with destroy_protected_branch

- Remove extra method for authorize_admin_project
- Ensure project presence
- Rename 'read_repo' to 'read_repository' to be more verbose

- When using 'read_repo' password and project are sent, so we used both
  of them to fetch for the token
- When using 'read_registry' only the password is sent, so we only use
  that for fetching the token