Hotchocolate: Nullability inference inside List

[benmccallum]

Describe the bug
It seems like pure code-first nullability inference doesn't quite work with List<T> as it comes out in the SDL as [T]! rather than [T!]!.

To Reproduce
In a project with nullable enable:

1. Extend a query type with the following:
   ```c#
   [ExtendObjectType(Name = nameof(GraphQLTypeNames.Query))]
   public class SomeResolvers
   {
   public async Task> GetFoos() => Task.FromResult(new List());

// Here's where [T]! makes sense
public async Task<List<string?>> GetFoos() => Task.FromResult(new List<string>());

// FYI, this works as expected and gives `T!`
public async Task<string> GetFoo() => Task.FromResult("");

// Note: In my case I'm using an entity class, not `string`, but I'm assuming it'd exhibit the same problem. If it doesn't try hooking up a POCO class wrapped in a schema type. 
// I'm using async but again, prob doesn't matter either.

}
```

1. Load up in playground UI and inspect the field's return type.

Expected behavior
See desc. I can obviously annotate it with [GraphQLType(typeof(NonNullType<ListType<NonNullType<StringType>>>))] but it's nice not to need to.

Desktop (please complete the following information):

• OS: Win 10
• HC Version 10.5 preview 2
• C# 8.0 w/ nullable enable

[PascalSenn]

Thanks for reporting this @benmccallum

I think this on is fixed in 11
https://github.com/ChilliCream/hotchocolate/issues/1600

[benmccallum]

Ah yep, that'll do it haha. I even looked for existing issues but that one didn't come up. Sorry!

I think it makes sense that this only goes out in v11 as it's technically a breaking change given it'll affect default typing output. Shouldn't matter to most, but is worth listing in v11 release notes, etc. As such, will close this.

cc: @michaelstaib

[benmccallum]

Note for anyone else, this should be fixed in 10.5 now too.

[benmccallum]

Correction, this isn't fixed for List<T>, but is for IEnumerable<T>, so I've swapped to that, which makes more sense to use anyway.

[PascalSenn]

Let's reopen this because the initial bug is not fixed.
@michaelstaib This is something we have to cover when we redesign typeinfo

[michaelstaib]

This one was already fixed in 11 a couple of days ago.... so I am closing it again.