Feature Request: Support for pre-processing and/or validation before resolvers begin running

I've been building an enterprise-tier product in AppSync and so far it's really living up to the task, but as the list of needs for the enterprise system grows, there are a couple things I find myself unable to do, and many of them would all be solvable with the same solution: support for a preprocessing lambda and postprocessing lambda at the entire-API level, such that can execute before your resolvers begin running or after total resolver execution has concluded, especially for checks that need vision on the whole GraphQL query in order to make sense.

# Use cases:

## Protect against nested attack that wastes resources

```
query {
getAuthor(authorId: "12345") {
name
books {
title
authors {
name
books {
... ad naueseaum
}
}
}
}
}
```

This is valid graphql a Client can ask your API for that the only defense against is not to make resolvers that go both ways on your types. Obviously there is a business case for seeing Books of an author as well as Authors of a Book. Individual resolvers don't have visibility on the entire query that was asked for and can't defend against this. A preprocessing lambda that had visibility of the entire query could stop it.

## Defense against getting unauthenticated records by going up the chain then down the chain

```
query {
getTwitterUser(userId: "12345") {
userHandle
tweets {
content
retweetedByUsers {
userHandle
tweets {
... could be backing into things i'm not allowed to see here!
}
}
}
}
}
```

This is an oversimplified example above, but essentially, you can break the `@auth` pattern that has been so useful in establishing ownership of certain rows, by asking for something that passes the auth check, then nesting into children, then nesting back out to their parents, then continuing to chain those nestings until you can see things you don't have access to. There are workarounds for this, but they all involve going in and getting really dirty in your resolvers with having to traverse all the way back up the chain and checking @auth again manually. Again, could defend against this from the very top level by having a preprocessing lambda that has visibility to see the entire graphql query.

## Taking a certain action on all resolvers without having to attach a pipeline function to all of them

We're up over 300 resolvers now in our API and there are some pretty universal transforms we do on all of them, such as doing an extra layer of authentication check against a source that isn't one of the AppSync premade auth sources, and writing an event to an Event Bus Architecture if the graphql call was a Mutation. Our solution to this has been to make some extra FunctionConfigurations and attach them to the PipelineConfigurations on each of the... 300+... resolvers. That's a code smell for sure. This would definitely be a real win if there was a global API-tier preprocessing and postprocessing lambda.

# Conclusion

Thank you for considering my feature request!

Start from the requested API-level preprocessing and postprocessing lambdas, then review how the existing resolver PipelineConfigurations are attached across the 300+ resolvers. Use the nested-query protection, authorization, and mutation event use cases to define the required behavior; done means a single API-level mechanism can cover these cases without per-resolver pipeline attachments.

Written by the indexing model from the issue text.