Add support for defining a limit in how nested queries can be

[abhishekkumams]

Currently, we do not limit the amount of nesting in our graphQl queries, which can result in long running queries.

Things to keep in mind:

1. Find the limiting depth such that a balance is maintained between limiting nesting depth and maintaining query flexibility.
2. Keep the Client Experience in mind. Deeply nested queries can provide more granular data, but they may also make the client code more complex.
3. Make sure to test the GraphQL queries, both within the nesting limit and at the limit's boundaries. Monitor query performance and resource usage to identify any bottlenecks or issues that may arise from the imposed nesting limit.

[Aniruddh25]

Configurable at the global runtime level.
Boolean or configurable limit?
Default?
SWA v/s On-premises scenario?

[aaronpowell]

https://github.com/ChilliCream/graphql-platform/blob/96b9a9c4198d7f13a15b10f617f536c1ca15d3c6/src/HotChocolate/Core/src/Execution/DependencyInjection/RequestExecutorBuilderExtensions.Validation.cs#L194 is the method in HotChocolate that would need to be called, it takes a number for the depth.

It probably makes sense to have that number as part of the runtime section of the config file, with a sensible default. It could be worth reaching out to the API Management GraphQL team to see if they have data on what is the most common depth they see and use that as a default.

[michaelstaib]

Adding a limit is often not enough for GraphQL APIs... with Hot Chocolate 14 we are introducing a lot of security policies to Hot Chocolate. One thing that might also be interesting to you is the IBM Cost Spec which allows to prevent threads, rate limiting and other things but also allows to better charge consumers for the impact they had to the system:
ChilliCream/graphql-platform#7146

The cost spec will enable:

• Threat Protection
• Rate Limiting
• Monetization

you can read up here:
https://ibm.github.io/graphql-specs/