feat(validation): include error messages in ValidationFailed exception message

[mgalexandre]

1. Implements ProvidesContext, exposing the errors as structured context, so they show up in log context via LoggingExceptionReporter and on the development exception page, the same pattern as QueryWasInvalid, EncryptionFailed, and ProcessExecutionWasForbidden.

2. Appends the failures to the message in a human-readable format:

Validation failed for App\User.
- credential: Passkey not valid
- email: Email is already taken; Email domain is not allowed

The message stays untouched (Validation failed.) when there are no error messages.

Fixes #2189

[innocenzi]

I don't think this is the right thing to do, honestly. Appending the JSON-encoded message array seems rough around the edges.

In what situations did you need the message property of the exception to contain the details, and you could not reach for errorMessages?

[mgalexandre]

I've reworked it to do two things:

• ValidationFailed now implements ProvidesContext (as @NeoIsRecursive suggested on the
  issue), exposing the errors as structured context for logs and the exception page.
• The message lists the failures in a readable format instead of JSON:
  Validation failed for App\User.
• email: Email is already taken

[innocenzi]

Right, didn't take a look at the original issue, thanks @mgalexandre

@brendt, in what situations do you need the message to contain the actual errors? I do think the context, as suggested by Neo, is more suited here

[brendt]

The problem I want solved is this one: you're testing HTTP endpoints with exceptions enabled (a common use case), and you run into a validation error. There's no way to see what's wrong here without making changes to the test code, which is very annoying.

That's the only thing that needs improvement. I don't really care how, but I want to see immediately in the exception message what's wrong

[innocenzi]

Thanks, yeah that's definitely and issue. Then I believe our exception renderer should be responsible for that instead of hijacking the exception message.

Maybe by showing the context for all exceptions, or by special-casing ValidationFailed?