Fix test flake revealed by #308

[benjaminjkraft]

Two issues here:

• In the with-config tests, we were generating all the different input files into one output. This makes sense in user code, but in our tests, we reuse the same types all over the place, so not only is it confusing to read all the tests interleaved, it can cause nondeterminism anytime our conflict-detection is incomplete (Validate against conflicting options on the same type #123). As it happens, Annotated optional fields with omitempty by using new optional config value #308 introduced such a case, so tests started flaking. Fixes Split TestGenerateWithConfig cases #281.
• This turned the case introduced by Annotated optional fields with omitempty by using new optional config value #308 from a flake into a consistent failure. The issue is actually unrelated to the changes in the PR (it's intentional validation added in omitempty validation on input fields with/without defaults #338, and specifically corresponds to errors/OmitemptyDirective.graphql from that PR), so I changed the config for the test case to one that avoids the issue while still testing what we want.

I have:

• Written a clear PR title and description (above)
• Signed the Khan Academy CLA
• Added tests covering my changes, if applicable
• Included a link to the issue fixed, if applicable
• Included documentation, for new features
• Added an entry to the changelog

[csilvers]

I understand how this PR fixes the first issue you mention in the commit message, but I'm not sure I understand the second. I'd like to hold off approving until I do.

I'm guessing that the change to add PokemonInput is what fixes the second issue? How does that fix anything?

[benjaminjkraft]

Yes, sorry, the second fix is to add the PokemonInput type to bindings. That means instead of autogenerating a Go type for that GraphQL type, we use the existing one. Generating the type hit one of the cases we now intentionally validate against (#338 -- where a global omitempty applies to a field that doesn't make sense for); we could fix it in other ways (e.g. an explicitly omitempty: false on that field) but this was more consistent with how the other tests treat this type, and I believe we already have tests for those other cases anyway.

[csilvers]

ok, sounds good!