`instance` and `type='required'` challenges

[lwjohnst86]

Here, we rewrite jsonpath so that for type="required" errors it ends in the missing field's name. I think that (regardless of having solved the hash problem) this should be matched by rewriting instance for required errors in the same way. Otherwise, we will end up with output like:

# check({"resources": [{"title": "Title"}]}, error=True)

At package.resources[0].name:
|
| name: {'title': 'Title'}
|       ^^^^^^^^^^^^^^^^^^
'name' is a required property

It would be nice if this could happen here and not in _create_issue, but I don't know off the top of my head if that would be problematic for any logic that relies on instance on SchemaErrors.

Originally posted by @martonvago in #208 (comment)

[martonvago]

@joelostblom replying to your comment here:

Hmm, that's a good point! That first issue in your example is a simplification of a group of errors in the jsonschema output. I just set the attributes on it in a way that made sense at the time, but we can change them if they don't lead to consistent behaviour.

• jsonpath: I set this to $.resources[i] because I couldn't set it just to $.resources[i].path or $.resources[i].data, as exactly one of these must be specified. Not sure what other options there are.
• instance: if we can't change jsonpath then I think this should remain as is (the resource), because jsonpath should really point to instance.
• type: while required is sensible enough for this issue, I think there's some wiggle room here. We could just set it to something like path-or-data-required and that would solve the problem.

Would this make sense to you?

I'll have a look at the other grouped jsonschema error simplifications to see if there are similar problems.