Limits errors in getVariableValues() and coerceValue().

[SoyYoRafa]

Fix for issue #1753. Errors are statically capped at 50. Unit tests added.

There is a bit of code duplication in checking whether the error limit is capped. The reason for this is that we want the cost of checking whether the limit is reached only when errors are being created and not during the execution and coercion of good values.

[IvanGoncharov]

@SoyYoRafa Thanks for PR 👍
BTW, you don't need fieldWithOneHundredInputs to create multiple query variables you can use fields aliases to do the same even for the fields with a single argument:

query($a:String!,$b:String!,$c:String!) {
  a: __type(name: $a) { __typename }
  b: __type(name: $b) { __typename }
  c: __type(name: $c) { __typename }
}

But before merging it I want to try to implemente same functionality with less code duplication and also try to fix some edge cases. For example in current implementetion this array will produce 100 of errors that will latter be dropped to 50:

[
  [... 50 bad values],
  [... another 50 bad values]
]

I will try to finish it this week.

[SoyYoRafa]

Ah, good to know! Could we please release the final merge result as part of version 14.x? We are keen on getting this issue fixed.

[IvanGoncharov]

Could we please release the final merge result as part of version 14.x?

It can be a breaking change if someone using graphql errors for client-side validation but it's something that we always discouraged, so I think it safe. Also, I think we need to publish CVE (low priority but still) after publishing this fix and I think it's bad to force users to update to 15.x.x just for this fix.

@mjmahone @martijnwalraven @abernix Can it a be breaking change if we will start limiting maximum number errors produced by validating/coercing query variables?

Note: We discuss only validation performed during execute and there are no plans to limit errors from validate.

[IvanGoncharov]

@SoyYoRafa Just as an update I'm still working on it.
Taking more time than I initially estimated since ATM I'm focusing on code & tests clean up.
But I'm pretty confident I will have my PR ready for review in a couple of days.

[mjmahone]

I don't have a strict problem with this, and it's unclear to me what a reference server implementation should do. I think the server ending up in an error state if there are too many GraphQL errors is acceptable, though.

[IvanGoncharov]

@SoyYoRafa Fixed in #2062. Thank you for this prototype I borrow a lot from it and this significantly speed up work on #2037