add support for query validation

[aryaniyaps]

adds a few validation rules which would be very useful in production environments. Documentation regarding validators have been added, and new test cases have also been made (which pass).

Similar validation rules are provided out of the box in other libraries like strawberry graphql and ariadne, so it would be nice for graphene users to get a similar experience.

validation rules which have been added:

• depth limit validator
• disable introspection

allows passing the validation rules to the validate method from graphql-core. Huge thanks to @jkimbo for his work on the depth limit validator, which was a port from https://github.com/stems/graphql-depth-limit

also fixes #907
also aims to fix CI, replacing travis CI with github actions

[aryaniyaps]

@syrusakbary could you please review this if you have the time? It would be really helpful to use in production environments. Please let me know if any changes should be made, I'll do it! Thanks a lot!

[syrusakbary]

I'm liking this PR! Could it be possible if we fix CI as part of the PR? (replacing Travis with Github CI should be good!)

[aryaniyaps]

@syrusakbary please check the new workflow I pushed in (also deleted the .travis.yml file). If any changes need to be done, please let me know! The PYPI_API_TOKEN secret needs to be set to automatically publish to PyPi, I think.

also, I think that parallel processing isn't required, because we need to execute jobs sequentially (first tests, then check coverage and finally publish). What do you think about this?

also, I created the workflow based on the .travis.yml file. I couldn't understand one thing and I am not sure about this.
Are we publishing a new version to PyPi for every PR? Or should that be done in a new workflow which fires whenever a new github version is released?

[syrusakbary]

The PR looks great, although tests are not passing (it seems to be an issue on master).

If you could help solving those last issues then we should be good to merge!

[aryaniyaps]

Sure, I've managed to find out the problem. There have been a few changes in graphql core lately. The ExecutionContext class provided by graphql-core doesn't eat up exceptions now.

You can check here for reference.
https://github.com/graphql-python/graphql-core/blob/afd03a058d04d12484dd920956d4611c50bf2f86/src/graphql/execution/execute.py#L580-L656

Therefore, we could fix the failing tests by removing UnforgivingExecutionContext and related tests (we dont need it anymore)

[aryaniyaps]

@AlecRosenbaum what do you think about this?

[AlecRosenbaum]

The ExecutionContext class provided by graphql-core doesn't eat up exceptions now.

If this was true, then the test suite should pass without specifying a custom context, right?

[aryaniyaps]

The ExecutionContext class provided by graphql-core doesn't eat up exceptions now.

If this was true, then the test suite should pass without specifying a custom context, right?

Yep, could you please check my commits (changed files for this PR)?

[AlecRosenbaum]

@syrusakbary Does it really make sense to block this change on unrelated test failures?

[syrusakbary]

Looks great, merging!

[aryaniyaps]

@syrusakbary I think you forgot to set PYPI_API_TOKEN or it is invalid.

[aryaniyaps]

@syrusakbary should a new release be made to make this feature available?