Add onError RFC

[martinbonnin]

This is a RFC that aims to extract the onError bits from the semantic nullability discussion, breaking down the initial problem in smaller, hopefully more manageable, problems.

Read the rendered RTC

[BoD]

Would it be simpler if the default is always PROPAGATE? That automatically makes this compatible with old clients, and removes the need to surface the default in introspection (unless there's another reason to do so that I missed?)

[martinbonnin]

From what I understand, we want clients to be able to omit onError in the end state. This was discussed in the May wg around here.

If you create a new schema now, it's reasonable to create it with a modern onError: NULL default so that clients do not have to send extra useless bytes for each and every request.

[calvincestari]

Suggested change

	* `PROPAGATE`: propagates the error to the nearest nullable parent field. This is the current behaviour.
	* `PROPAGATE`: propagates `null` and the error to the nearest nullable parent field. This is the current behaviour.

I think having only "the error" could be misinterpreted and it's clearer to state that the null value is propagated too.

[martinbonnin]

The spec text is currently only mentioning propagating "errors":

If during ExecuteSelectionSetwith a non-null type raises an execution error then that error must propagate 
to the parent response position (the entire selection set in the case of a field, or the entire list in the case 
of a list position), either resolving to null if allowed or being further propagated to a parent response position.

Alternative suggestion (also with position instead of field):

Suggested change

	* `PROPAGATE`: propagates the error to the nearest nullable parent field. This is the current behaviour.
	* `PROPAGATE`: propagates the error to the nearest nullable parent response position where the error then resolves to null. This is the current behaviour.