Separate schema and execution config

[namnm]

Right now the schema is also carry the execution config. For eg a schema is created as following:

var schema = Schema.Create(c =>{
    c.RegisterType(new QueryType());
    // TODO Register other types here

    // These configurations should be moved to another class for execution
    c.RegisterServiceProvider(new MyServiceProvider());
    c.Options.ExecutionTimeout = TimeSpan.FromSeconds(TIMEOUT);
    c.Options.DeveloperMode = DEVELOPMENT;
});

We should move the above config to another class, so the schema can be construct without the context (for eg ServiceProvider), and may be it can be stored statically as a singleton. Or we can modify the signature of Execute extension to take a service provider as a param.

[michaelstaib]

The ISchema represents the executable schema. We might change the name an introduce something like a schema build from which the executable schema can be created. I have mot found an ideal solution but have targeted this under the label SchemaBuilder for version 0.11.0 in our roadmap.

[michaelstaib]

We now have a QueryExecutionBuilder that contains the options, services and middleware components that belong to the execution. The next step is moving the options and making the options property on the schema configuration obsolete.

[michaelstaib]

The following options shall be moved:

int? MaxExecutionDepth { get; }
TimeSpan ExecutionTimeout { get; }
bool DeveloperMode { get; }

[michaelstaib]

Do we still need developer mode. Since we now have the exception handler. The only thing developer mode does is writing fill exceptions into the query errors. We could instead add a developer error handler and let this guy do exactly that.

[michaelstaib]

This one is now implemented with 0.7.0-preview.19