Make all limits of the of the complexity to be configurable via the CLI

[xgreenx]

[netrome]

Input from grooming: Just adding all of these as CLI args with the given defaults seems like a good starting point.

[acerone85]

Started having a look at this. It does not look like we can easily change the #[graphql(complexity = "QUERY_COSTS.query_name")] field to use values computed at runtime.
See for example

fuel-core/crates/fuel-core/src/schema/balance.rs

Line 56 in 749e732

#[graphql(complexity = "QUERY_COSTS.balance_query")]

.

In particular, async_graphql checks the complexity in the validation phase, whereas the code of the query corresponds to what is executed in the execution phase. So, even if you added the query complexity costs in the execution context, it won't be possible to compare these values against the actual query complexity.

A better approach seems to be using async_graphql extensions. In particular, it looks that the analyzer extension can be tweaked to limit query complexity with values specified at runtime. Note that extensions are run against all graphQL requests, not only queries.

Pinging @xgreenx to validate the approach.

[netrome]

Started having a look at this. It does not look like we can easily change the #[graphql(complexity = "QUERY_COSTS.query_name")] field to use values computed at runtime. See for example

fuel-core/crates/fuel-core/src/schema/balance.rs

Line 56 in 749e732

#[graphql(complexity = "QUERY_COSTS.balance_query")]

.

In particular, async_graphql checks the complexity in the validation phase, whereas the code of the query corresponds to what is executed in the execution phase. So, even if you added the query complexity costs in the execution context, it won't be possible to compare these values against the actual query complexity.

A better approach seems to be using async_graphql extensions. In particular, it looks that the analyzer extension can be tweaked to limit query complexity with values specified at runtime. Note that extensions are run against all graphQL requests, not only queries.

Pinging @xgreenx to validate the approach.

Actually the complexity expression is evaluated at runtime so if we can do

#[graphql(complexity = "my_complexity_function()")] 

Where the function could have access to some lazy static value that we initialize once the system starts up.

Though extensions may be a better way to go about it.

[netrome]

If we do write an extension here, we need to be careful not to hit the same race condition as in #2330 (comment). We could probably use the same solution, but perhaps it's simpler to just use a OnceLock that we write to when we parse the configuration. I don't think that would be too complex, and the overhead of this approach should be should be negligible.