UI: allow navigation to subdirectory

[hellobontempo]

This partially fixes the request here #5362 so users can LIST at the secret level in the UI.

Fixes #20563 and #13188 and #20563

The user in the gif has the following policy where they can only LIST at the my-secret/ level. Previously a user had to know the full secret path to view this list of secrets, now they just need the top-level secret path:

path "my-kv/metadata/my-secret/*" { capabilities = ["list", "read"] }
path "my-kv/data/my-secret/*" { capabilities = ["list", "read"] }

---

If a user can only list metadata at the top level, so with a policy that looks something like:

path "my-kv/data/*" {
  capabilities = ["read", "list", "delete"]
}
path "my-kv/metadata" {
  capabilities = ["list"]
}

The input in the card pre-fills with the path selected from the list view

[hellobontempo]

small styling fix I noticed

[github-actions]

Build Results:
All builds succeeded! ✅

[Monkeychip]

Big improvement with a little code. Nice work!

[hellobontempo]

rebase bonk up, closing in favor of #22455

[schavis]

Will finish reviewing the other content updates on Monday

[schavis]

Suggested change

	- `password` `(string: <required>)` – The password for the LDAP user.
	When authenticating with the Vault CLI, i.e. `vault login -method=ldap username=mitchellh`
	- `password` `(string: <required>)` – Password for the LDAP user authenticating with the Vault CLI.

[schavis]

Suggested change

	When a role is not explicitly specified, behavior is specified by the
	`default_directory_policy` in the [ACME configuration](#set-acme-configuration).
	These directories can also be forbidden by setting that policy as `forbid`. If
	the policy is `sign-verbatim` then _any_ identifier for which the client can
	prove ownership of will be issued for. This is similar to using the
	[Sign Verbatim](#sign-verbatim) endpoint, but with additional verification
	that the client has proven ownership (within the ACME protocol) of the
	requested certificate identifiers. When `external-policy` is specified as the
	default value, the CIEPS engine <EnterpriseAlert inline="true" /> is used for
	validating and templating the certificate instead of a role; ACME's challenge
	validation is still enforced. An optional policy name can be specified by using
	`external-policy:policy`. Roles are not used when CIEPS is used.
	When a role is not explicitly specified, Vault uses the default policy set by
	`default_directory_policy` in the [ACME configuration](#set-acme-configuration):
	- `forbid`: denies access to the directory
	- `sign-verbatim`: allows access to clients that provide *any* identifier
	they can prove ownership for. `sign-verbatim` behaves like the
	[Sign Verbatim](#sign-verbatim) endpoint but with the additional verification
	that the client can prove ownership within the ACME protocol of the requested
	certificate identifiers.
	- `external-policy`: <EnterpriseAlert inline="true" /> uses the CIEPS engine to
	validate and template the certificate instead of a role with ACME challenge
	validation. You can specify an optional policy name with `external-policy:policy`.
	Roles are not used when CIEPS is used.

Style correction: write in active voice, make options scannable

[schavis]

Suggested change

	Similar to the [generate certificate and key](#generate-certificate-and-key)
	endpoint, this endpoint generate key material and certificate via an external
	policy engine. The private key material stays local to Vault, with the external
	service getting only an empty CSR. Any parameters passed to this endpoint are
	passed verbatim to the CIEPS engine <EnterpriseAlert inline="true" />. The
	response format is the same between both endpoints.
	Similar to the [generate certificate and key](#generate-certificate-and-key)
	endpoint, this endpoint generate key material and certificate via an external
	policy engine. The private key material stays local to Vault, with the external
	service getting only an empty CSR. Any parameters passed to this endpoint are
	passed verbatim to the CIEPS engine <EnterpriseAlert inline="true" />. The
	response format is the same between both endpoints.
	``````suggestion
	Similar to the [generate certificate and key](#generate-certificate-and-key)
	endpoint, the external policy endpoint generates key material and certificate
	through an external policy engine. The private key material stays local to
	Vault and the external service receives an empty CSR. All parameters passed
	to the endpoint are passed, verbatim, to the CIEPS engine <EnterpriseAlert inline="true" />.
	The response format is the same between both endpoints.

Style correction: simplify language, write in active voice

[schavis]

Suggested change

	It is suggested to limit access to the path-overridden issue endpoint (on
	`/pki/issuer/:issuer_ref/external-policy/issue/:policy`) and let the CIEPS
	engine override the issuer as necessary.
	We recommend you limit access to the path-overridden issue endpoint (on
	`/pki/issuer/:issuer_ref/external-policy/issue/:policy`) and let the CIEPS
	engine override the issuer as necessary.

Style correction: active voice

[hellobontempo]

Will finish reviewing the other content updates on Monday

Hi @schavis - sorry you got pinged on this! This was the result of rebase chaos and those commits aren't actually part of my PR. I attempted closing this PR before anyone could start reviewing - but you were too quick! 🙈