[Docs] Adding identity-based rate limit

[yhyakuna]

Description

🎫 Jira ticket

This PR updates resource quota docs for Vault 1.20.0:

• Update the resource quota docs to mention adaptive overload protection 🔍 Deploy preview
• Add "Create a rate limit quota" page 🔍 Deploy preview
• Add "Identity-based rate limit quotas" page 🔍 Deploy preview

---

TODO only if you're a HashiCorp employee

• Backport Labels: If this fix needs to be backported, use the appropriate backport/ label that matches the desired release branch. Note that in the CE repo, the latest release branch will look like backport/x.x.x, but older release branches will be backport/ent/x.x.x+ent.
  • LTS: 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]

CI Results:
All Go tests succeeded! ✅

[github-actions]

Build Results:
All builds succeeded! ✅

[bosouza]

In these more explanatory docs I think we should explain what we mean by "buckets" before using such terminology to explain something else

[hc-meredith]

That's a good point. Maybe something like:
For rate limit quotas, we use a concept called a "bucket". This essentially defines a group of requests based on a certain characteristic they have in common. For example, if we have chosen to group_by IP, there would be one bucket for each IP that is sending requests. Each bucket has the rate limit R which is set at the namespace, path, mount, role, or global level.

[bosouza]

I think explicitly calling out "namespace, mount or path" might imply that a quota's group_by mode has something to do with whether or not a quota matches against a given request, when in fact it does not.

Quotas can be configured at a global, namespace, mount, path or role levels, which only affects the decision of which (if any) quota applies to any given request. Then, that matching quota can be configured to group requests by different attributes, namely "ip", "none", "entity_then_ip" and "entity_then_none", which affect how that matching quota is applied.

[hc-meredith]

I think you're right. At the same time, though, I want to make sure we're being explicit about how they can use the rate limit quotas - there are a lot of customer misconceptions that they can impose a limit on a specific user, for example, and I want to make it clear that that's not what we're allowing them to do.

[bosouza]

secondary_rate is not a group_by mode, they're both separate fields in the RLQ definition. As you described above, for requests without an associated entity Id we group by either IP (on entity_then_ip) or all together (on entity_then_none), allowing all buckets rate requests per second, but if secondary_rate is set then we use that instead for the secondary (IP/collective) bucket

[bosouza]

it's also possible to define an RLQ for a role. Role-based RLQs have the highest priority. You can find a more thorough description of the evaluation priority in this section of the RFC https://docs.google.com/document/d/1puB0Yfsmew35Z7YdliFqvgHXldlmTsux9hAtwtV37EY/edit?tab=t.0#heading=h.5g040uvfvj1q