Update best practices for recording rules

Proposal

Use case. Why is this important?
I found the best practices on recording rules very useful, but one part missing in the naming section is what to do if you have a filter/query in your expression. I'm trying to make a ratio and it uses the same metric, but the numerator has a filter to it (e.g. 4xx / total requests).

Even if this is an anti-pattern that should at least be stated in the best practices section and why. Looking at the builtin ones from my helm chart don't use any difference in their names, but the best practices section is heavily opinionated that the name should be derived from what you're doing.

Additionally, is there documentation explaining recording rules and performance best practices? I've seen blog entries that explains that compute is being distributed, but doesn't exactly say why. In the doc it seems to make a rule for each operation. That seems like it's exploding how many metrics you have, so it'd be nice to understand why this is the better approach and how it works under the covers.

Start by locating the existing best-practices section on recording rules and the current documentation on recording-rule performance. Review how naming guidance handles filtered expressions, then document the expected naming approach and explain the performance and metric-cardinality tradeoffs. Done means both questions are addressed clearly in the relevant documentation.