Enhance validation error handling in ValidationEndpointFilterFactory using IProblemDetailsService

[marcominerva]

Modify validation error handling to utilize IProblemDetailsService for response writing

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

This PR updates the ValidationEndpointFilterFactory to improve how HTTP validation errors are handled, specifically by integrating with the IProblemDetailsService for enhanced response customization. The changes include adjustments to the response logic and dependency usage.

Description

• Integration with IProblemDetailsService: Added logic to check for and utilize IProblemDetailsService to write custom problem details responses if available. This allows for more flexible and centralized error handling.
• Fallback to default implementation: Ensured a fallback mechanism to return HttpValidationProblemDetails if IProblemDetailsService is not present.

Fixes #61219

[martincostello]

I imagine the team will want a test for this.

[marcominerva]

At the moment, there are no tests at all for the ValidationEndpointFilterFactory class. I need to figure out the correct way to add them, but in the meantime, I decided to open the PR because I’d like to understand whether this is the right approach.
Specifically, I’m referring to returning EmptyHttpResult.Instance: I’ve verified that it works, but I’m wondering if there’s a better solution.

In the meantime, I’ll think about adding a test.

[martincostello]

Just suggested it as it wasn't a draft 😃

[marcominerva]

You're right, @martincostello — I just converted the PR to a draft until the tests are done. 😉 But in the meantime, as said I would love to know if I'm going in the right direction.

[marcominerva]

I finished earlier than expected. I’ve added a couple of tests, so the PR is now ready for review.

[captainsafia]

@marcominerva Thanks for taking the time to working on this! Sorry I never got back to your question on the issue.

At the moment, there are no tests at all for the ValidationEndpointFilterFactory class. I need to figure out the correct way to add them, but in the meantime, I decided to open the PR because I’d like to understand whether this is the right approach.
Specifically, I’m referring to returning EmptyHttpResult.Instance: I’ve verified that it works, but I’m wondering if there’s a better solution.

There's coverage for the filter in the ValidationsGenerator tests which execute the end-to-end but adding individual tests is good.

One thing to note is that since we don't have a runtime type resolver (see #61220), we won't be able to test validation against complex types but that might be fine for the purpose of this test.

[captainsafia]

I think with this pattern, we've lost the ability for users to add endpoint filters after this one that can inspect what the validation errors that were returned were. Since we lack ModelState in minimal APIs, this might be the only way for users to understand the error state.

[marcominerva]

In fact, this is the point I mentioned I was unsure about.

However, I have verified that, even with the current implementation, custom endpoint filters are not invoked when validation fails, or am I missing something?