Add Execution middleware

[sahil-nyt]

Allows a repo to use a chain-of-responsibility pattern to affect the execution behavior of graphql-go. Done for this use case: https://github.com/nytimes/scoop/pull/4863#discussion_r1987991818

[tilgovi]

What can be done with this that cannot be done by wrapping the root operation resolvers? It seems like the use case described might be served by wrapping the root Query operation resolver, which receives all of the resolve parameters already parsed and prepared and such.

[tilgovi]

I guess the way graphql-go structures things, it first determines the operation and then executes the fields. There's no resolver for Query or Mutation that ever gets called, so I'm a little off.

I could imagine deferring some things to the top-level field resolvers that we currently do in extensions, but I don't know if it's pretty. For example, the repo extension could try to defer acquisition of a connection to the field level, and somehow ensure that (through some context value) all fields acquire the same connection. Similar might work for single-flight. But maybe that's uglier than what you have here.

[chrisfrank]

This approach looks really nice to me, but to avoid diverging too much from upstream graphql-go, I think we should constrain our changes to either bug fixes or places where we're missing features from graphql-js. It looks like the graphql-js team considered and rejected an official middleware layer, so we should consider handling this in our app instead.