docs: add guide for operation complexity controls

[sarahxsanders]

Adds guide "Operation Complexity Controls"

[benjie]

This is really good, and I'm excited to see us addressing this topic! However, ideally we should not promote a particular module for complexity analysis (unless it's one we control), otherwise we open ourselves to adding that to GraphQL.js' security surface area, and we artificially limit competition/innovation within the ecosystem. Instead we should talk about it in more general terms (and perhaps give a few examples of modules that can be used for this). In addition:

1. We should strongly encourage the use of trusted documents over complexity limits at runtime
2. We should note that complexity limits can be subject to attack themselves (for example, via fragment cycles), so it's generally best to run them after validation but before execution unless we know they're safe to run alongside validation
3. The validation phase doesn't have access to variables (validation tends to happen once per document independent of variables) so complexity limits depending on variables will need special plumbing
4. Certain field types make operations more complex, in particular lists (and, to a lesser extent, abstract types); we should comment how these "multiply up" the complexity.
5. We should note that this should form part of a layered security approach - referencing https://graphql.org/learn/security/
6. We should note that with trusted documents, complexity analysis can still be valuable to warn engineers about expensive operations, and can mostly be done at build-time rather than run-time.
7. We should be careful with the use of the word "query", because we're talking about mutations and subscriptions too really. Consider "operation" or "document" as appropriate (glossary), or simply elide "query" entirely: "complexity controls".

I don't think you need to change the document very much to accommodate this feedback - e.g. you can keep all the examples, just make it very clear that they're just examples from one of the modules and other approaches are available.

[sarahxsanders]

@benjie thanks for much for the thorough feedback! My next commit has the following updates:

• Renamed the guide to "Operation Complexity Controls" and replaced mentions of "query complexity"
• Clarified tool neutrality, making it clear that graphql-query-complexity is one example among several (happy to expand on this more if needed)
• Added some callouts to address some of your other points (trusted documents, cycle safety and validation timing, etc.)
• Reworked the best practices to align with updates from your feedback
• Tried to position complexity analysis as part of a layered security approach instead of a standalone solution

Please let me know if there's anything else we should update! :)