Gate the the secrets manager empty state button on user abilities

What does this MR do and why?

⚠️ Depends on !256662 (merged) being merged first.

This uses the newly-passed can_provision and can_create_secret abilities from the backend as the SSOT for when to show the New secret button in the empty state of the secrets manager.

By default, only Owners can provision. Reporter+ should not be able to see see the New secret button unless the secrets manager is already provisioned by the Owner and they are explicitly granted permission to create secrets. Note that upon provisioning the secrets manager, only Owners are granted Read/Write access by default. Read/Write permission must be explicitly granted to Reporter+ roles or users for them to create secrets.

Out of Scope

We have a gating issue where Maintainer may land on the trial empty state (screen with trial/enable add-on CTAs) instead of the normal empty state (screen with New secret button). This is a known bug but is outside the scope of this MR. See !256976 (comment 3888579566) for the discussion and where to track the fix for this.

References

Fix for #629254 (closed).

Screenshots or screen recordings

This is what Reporter+ (except Owner) now experiences when they see the empty state (when secrets manager is unprovisioned).

Before	After

Upon provisioning, only Owners are granted write access by default. Read/Write permission must be explicitly granted to Reporter+ roles or users for them to create secrets.

No Read/Write permission	With permission

How to set up and validate locally

Setting up the secrets manager

1. Make sure you're running on SaaS: GITLAB_SIMULATE_SAAS=1 gdk start

2. Set up the GDK with OpenBao: https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/openbao.md

3. Enable the following feature flags: secrets_manager, group_secrets_manager, secrets_manager_namespace_enrollment, secrets_manager_paid_experience.

4. Create a new top-level group. This will be our test group. Add another Reporter+ user here (not Owner).

5. The entitlement resolver communicates with the CDot API. We will monkey-patch this and mock the results of the API so we can control the entitlement state locally. To mock the API, add these files config/secrets_manager_stub.yml and config/initializers/zz_secrets_manager_stub.rb and restart your gdk. This will mock the entitlement state returned by GraphQL (which we normally get from CDot).

   secrets_manager_stub.yml

   zz_secrets_manager_stub.rb

These will allow you to test with different entitlement states. By default, it is trial_eligible. If you need to clear/reset the cached entitlement, run SecretsManagement::Entitlement.stub_reset! from the rails console.

Verifying the feature

1. Change the entitlement state in config/secrets_manager_stub.yml to paid. This skips having to enroll and makes testing easier;.
2. Go to /path-to-your-tlg/-/secrets as a Reporter and verify that you can't see the New secret button.
3. Switch to Owner view. You can click on New secret button to provision the secrets manager.
   • After that, an alert shows up with a Manage permissions link. Follow this link to go to the settings page. Add a new permission for Reporter that allows them to Read metadata and Write.
4. Go back to the secrets manager page as a Reporter. You should now be able to create secrets.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.