UI: Fix enabling replication capabilities bug

[hellobontempo]

Description

A user with the policy below (which is used in this tutorial) was unable to enable replication in the GUI because the UI wasn't checking specifically for /dr/ or /performance/ in the original capabilities check.

// original check, path didn't include type
canEnablePrimary: this.store
        .findRecord('capabilities', 'sys/replication/primary/enable')
        .then((c) => c.canUpdate),
      canEnableSecondary: this.store
        .findRecord('capabilities', 'sys/replication/secondary/enable')
        .then((c) => c.canUpdate),

Now type is included in the path passed to the capabilities endpoint which hides or shows "Enable" accordingly. If there's a problem reading capabilities, then the default is true because the backend can be used as a fallback to gate a user who does not have the correct permissions.

I will open a manual backport to address this fix in 1.16 and 1.17 because the capabilities service is new and was added in 1.18

---

📸 The left is before the fix, and on the right is after.

Both browsers the user is logged in with the policy below.

# To enable DR primary
path "sys/replication/dr/primary/enable" {
  capabilities = ["create", "update"]
}

# To generate a secondary token required to add a DR secondary
path "sys/replication/dr/primary/secondary-token" {
  capabilities = ["create", "update", "sudo"]
}

# To create ACL policies
path "sys/policies/acl/*" {
  capabilities = ["create", "update", "list"]
}

# Create a token role for batch DR operation token
path "auth/token/roles/*" {
  capabilities = ["create", "update"]
}

# Create a token
path "auth/token/create" {
  capabilities = ["create", "update"]
}

# To demote the primary to secondary
path "sys/replication/dr/primary/demote" {
  capabilities = ["create", "update"]
}

# To enable DR secondary
path "sys/replication/dr/secondary/enable" {
  capabilities = ["create", "update"]
}

# To generate an operation token
path "sys/replication/dr/secondary/generate-operation-token/*" {
  capabilities = ["create", "update"]
}

# To promote the secondary cluster to be primary
path "sys/replication/dr/secondary/promote" {
  capabilities = ["create", "update"]
}

# To update the assigned primary cluster
path "sys/replication/dr/secondary/update-primary" {
  capabilities = ["create", "update"]
}

# If you choose to disable the original primary cluster post-recovery
path "sys/replication/dr/primary/disable" {
  capabilities = ["create", "update"]
}

TODO only if you're a HashiCorp employee

• Backport Labels: If this PR is in the ENT repo and needs to be backported, backport
  to N, N-1, and N-2, using the backport/ent/x.x.x+ent labels. If this PR is in the CE repo, you should only backport to N, using the backport/x.x.x label, not the enterprise labels.
  • If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[github-actions]

Build Results:
All builds succeeded! ✅

[github-actions]

CI Results:
All Go tests succeeded! ✅

[hellobontempo]

I thought about not using the new service here so that it more cleanly backported to older versions (this only exists in 1.18 so far), BUT the service is nice because we only make one request for all of these capabilities instead of a request for each path which I think is a win! 🙌

[hellobontempo]

I wanted to explicitly check for each mode instead of do a ternary statement since that'd mean if there wasn't a mode we'd fallback on a whichever was the falsy capability which didn't feel like the most stable thing to do.

[hellobontempo]

This wording feels strange? Open to alternatives!

[hellobontempo]

🔤 alphabetized 🤓

[hellobontempo]

added these comments so future devs see they are used here if performing a global search for the capabilities defined in the route

vault/ui/lib/replication/addon/routes/application.js

Lines 57 to 60 in 6efc65a

	canEnablePrimaryDr,
	canEnableSecondaryDr,
	canEnablePrimaryPerformance,
	canEnableSecondaryPerformance,

[hellobontempo]

originally I wrote all these variables as canEnableDrPrimary or canEnablePerformancePrimary but I found it easier to read with the type at the end and the cluster in the middle. Dr seemed to get lost in the middle there

[hashishaw]

Beautiful ✨