[Feature Request] PKI Engine: Rate Limiting per CN/SAN to prevent Raft storage exhaustion (DoS vector)

**Is your feature request related to a problem? Please describe.**
Yes. Currently, the PKI secrets engine is highly vulnerable to an asymmetric Denial of Service (DoS) attack or accidental infrastructure collapse caused by a single malfunctioning (or compromised) valid client.

If a client node enters a read-only filesystem state (e.g., due to a disk error), agents like `consul-template` or `nomad` will successfully request an mTLS certificate from Vault, fail to save it locally, and immediately retry. This creates a tight, infinite loop. Since Vault defaults to storing all issued certificates in the storage backend (to support CRLs), a single broken client can generate hundreds of thousands of certificates in a few days.

This rapidly bloats the Raft database to multiple gigabytes, leading to:

1. Severe I/O bottlenecks and HTTP timeouts.
2. OOM (Out of Memory) kills on Vault nodes.
3. Total cluster degradation.
4. Snapshots becoming so large that `vault operator raft snapshot restore` fails consistently due to hardcoded I/O timeouts, making disaster recovery extremely painful.

**Describe the solution you'd like**
We urgently need a built-in Rate Limiting feature at the PKI role level, similar to Let's Encrypt's duplicate certificate limits.

Vault should have configuration options such as:

* `max_requests_per_cn` (e.g., 5)
* `rate_limit_window` (e.g., 1h)

If a client requests a certificate with the exact same Common Name (CN) or Subject Alternative Name (SAN) more than $X$ times within the time window, Vault should reject the request with an `HTTP 429 Too Many Requests`. This would instantly stop the storage exhaustion loop.

**Describe alternatives you've considered**

1. **`no_store = true`**: This prevents Raft bloat, but it is not a viable workaround for environments that strictly require CRLs to be functional.
2. **`Automatic Tidy`**: While helpful for general cleanup, Tidy cannot keep up with a tight loop generating thousands of certificates per minute. Furthermore, BoltDB does not automatically shrink its physical file size on disk after Tidy deletes the entries, meaning the damage to storage is already done.
3. **External API Gateways/Load Balancers**: Difficult to implement rate limiting per-CN because the requested CN is encrypted inside the TLS payload or CSR body, which L4 load balancers cannot inspect.

**Explain any additional use-cases**
Beyond infrastructure bugs, this is a critical security enhancement. Currently, if an attacker compromises a single low-privileged node that has permission to request its own mTLS certificate, they can intentionally spam the Vault PKI endpoint. Without rate limiting, the attacker can easily bloat the Raft database and take down the entire centralized secrets management infrastructure for the whole organization.

Implementing rate limits on duplicate certificate generation is a standard industry practice (e.g., Public CAs) and is highly needed in Vault PKI.

Start by tracing the PKI role configuration and certificate issuance endpoint described in the issue, then examine how issued certificates are stored for CRLs. Define how per-CN or SAN counters, windows, and HTTP 429 responses should interact with existing requests. Done means repeated matching requests are limited without breaking required CRL storage, and the Raft-exhaustion scenario is covered by tests.

Written by the indexing model from the issue text.