Hotchocolate: [Spread] object argument into separate arguments

[benmccallum]

As discussed privately in Slack.

Desired behaviour

Possibility to be able to annotate a resolver method argument to be "spread". Happy to discuss alternate names, just thought it kinda works like a JS spread operator on an object.

```c#
// Resolver method
public Uri GetQuoteUrl(
[Spread] QuoteUrlParameters input)
=> _mediator.Send(input);

// Input class
public class QuoteUrlParameters
{
///

A vehicle's make, e.g. Ford

public string VehicleMake { get; }

/// <summary>A vehicle's model, e.g. Fiesta</summary>
public string? VehicleModel { get; }

[GraphQLIgnore] public string Ignored { get; set; }
// ctor

}

```graphql
type query {
    quoteUrl(
        "A vehicle's make, e.g. Ford"
        vehicleMake: String!, 

        "A vehicle's model, e.g. Fiesta"
        vehicleModel: String
    ): Uri!
}

Why?

1. Allows FEDs to see the api surface with args at the top-level, like GitHub's API for instance, but allows us on BE to get an object constructed for us that we can:
   
   
   
   1. Validate with FairyBread
   
   
   2. Fire as a MediatR IRequest
   
   
2. Further to that, XML documentation can be picked up and exposed out of the schema.

Design

Annotating an argument

1. SpreadAttribute
   
   
   
   1. Supported directly on argument in resolver method.
   
   
   2. Supported on object class itself (QuoteUrlParameters) in scenario above (to be applied in all uses).
   
   
2. Extension method for fluent-style setup

All above would use a descriptor to then set a flag that can be picked up by the type interceptor.

Rewriting arg and init'ing object

Use a type interceptor. Examples:

• NodeFieldTypeInterceptor
• IntrospectionTypeInterceptor
• SchemaDefinitionTypeInterceptor
• StitchingTypeInterceptor

Would replace the annotated arg with the arg's type's properties/fields as per current HC type reflection method.

Would hook up a middleware that takes the arguments and instantiates the full type as per current HC object input arg creation.

Relates to

• A request from @RohrerF (issue #773) Michael mentioned which essentially wants the opposite.

[benmccallum]

Feel free to chuck some thinking on here @michaelstaib / @PascalSenn .

I think the annotating part would be easy enough, I just need more details/design on how the rewriting arg and instantiating it on use would work. Given those concepts already exist in HC, it'd be great to be able to re-use existing functionality that knows how to build args list for a type T and similarly the functionality that knows how to pluck args and use T's ctor.

[benmccallum]

@maraisr this will interest you and allow us to not use the input: SomeInput convention in queries too for the convenience it provides. Best of both worlds :)

[RohrerF]

@benmccallum The issue I created a while ago would be #773