Extend query depth limiter allowing for more detailed rules

[tsmith023]

Enhances the query depth limiter by providing options to specify additional rules for fields within the GraphQL query.
These can be the field name on its own or including the field arguments.

Description

Exposes the new should_ignore argument to QueryDepthLimiter that takes a single argument of type IgnoreContext allowing the user greater verbosity when defining their rules. This dataclass can be extended to provide more ignore options by future PRs in response to further feature requests driven by specific use cases.

This functionality does not replace previous functionality but simply extends it. So you can still use the QueryDepthLimiter extension as it was previously implemented but now you can also use the further verbose functionality. However, the previous implementation is deprecated and will be removed in future releases.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

• Update query depth limiter ? #2338

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[botberry]

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

---

This release introduces the new should_ignore argument to the QueryDepthLimiter extension that provides
a more general and more verbose way of specifying the rules by which a query's depth should be limited.

The should_ignore argument should be a function that accepts a single argument of type IgnoreContext.
The IgnoreContext class has the following attributes:

• field_name of type str: the name of the field to be compared against
• field_args of type strawberry.extensions.query_depth_limiter.FieldArgumentsType: the arguments of the field to be compared against
• query of type graphql.language.Node: the query string
• context of type graphql.validation.ValidationContext: the context passed to the query
  and returns True if the field should be ignored and False otherwise.
  This argument is injected, regardless of name, by the QueryDepthLimiter class and should not be passed by the user.

Instead, the user should write business logic to determine whether a field should be ignored or not by
the attributes of the IgnoreContext class.

For example, the following query:

"""
    query {
      matt: user(name: "matt") {
        email
      }
      andy: user(name: "andy") {
        email
        address {
          city
        }
        pets {
          name
          owner {
            name
          }
        }
      }
    }
"""

can have its depth limited by the following should_ignore:

from strawberry.extensions import IgnoreContext


def should_ignore(ignore: IgnoreContext):
    return ignore.field_args.get("name") == "matt"


query_depth_limiter = QueryDepthLimiter(should_ignore=should_ignore)

so that it effectively becomes:

"""
    query {
      andy: user(name: "andy") {
        email
        pets {
          name
          owner {
            name
          }
        }
      }
    }
"""

Here's the tweet text:

🆕 Release (next) is out! Thanks to @t1mmysm0th for the PR 👏

Get it here 👉 https://github.com/strawberry-graphql/strawberry/releases/tag/(next)

[codecov]

Codecov Report

Merging #2505 (71de85a) into main (a621868) will increase coverage by 2.85%.
The diff coverage is 97.22%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2505      +/-   ##
==========================================
+ Coverage   93.60%   96.45%   +2.85%     
==========================================
  Files         198      198              
  Lines        8177     8244      +67     
  Branches     1478     1500      +22     
==========================================
+ Hits         7654     7952     +298     
+ Misses        379      184     -195     
+ Partials      144      108      -36     

[tsmith023]

Linking the previous review here: #2501 (comment) 😁

Edit: @patrick91, thanks for flagging that missing test! It identified a subtle bug within the validation logic!

[tsmith023]

@patrick91, this PR is in a state to be reviewed :D

Edit: anybody? 😭 @DoctorJohn @BryceBeagle

[patrick91]

Can you tell me more about this feature? what's your use case?

Also in terms of API, I wonder if we could use callables instead of field rules. I think that might make our implementation shorter, and potentially the api could be easier to use 🤔

[tsmith023]

The use case is that described in #2338, which allows to limit the depth of queries depending on the arguments of specific fields in addition to the names of said fields.

Let's have a discussion in Discord on the implementation detail of callables instead of FieldRules as I'm not 100% clear on how that would look in the code 😁

I had also hoped to limit based on the sub-fields of a specific field, but this wasn't doable with my implementation. Perhaps callables would help here!

[tsmith023]

@patrick91, this PR has been refactored to take into account the callables discussion we had previously. If you have time to review it then it should be ready to merge!

[patrick91]

thanks for adding the deprecation 😊

[patrick91]

we might want to move these out at some point, or reuse something classes we already have