Fix management API validation path casing

[Migaroez]

Prerequisites

Fixes #16926

Description

This PR aims to align the custom complex (nested) validation messages with the default MVC attribute ones. It does it by adding a ValidationMetaDataProvider that only updates ValidationModelName if it believes the context is inside the management api.
This way, other uses of MVC (rendering, implementor controllers, ...) should not be affected

Because these validation path segments that we modify are cached by the MVC framework and we can't guarantee that a certain class will not be used as both a top level and sub level model, I don't see a way to add the leading $. It was agreed with the front-end that they will add this on their end.

Testing

See the linked issue for the happy flow, but please do try to break this.

[AndyButland]

This looks good to me. I've tested it out locally verifying that it's updating the casing of these properties, and, as you've implemented it, it seems to be sufficiently tightly constrained to the management API models.

[kjac]

I haven't tested this, but if I'm reading the code correctly, this effectively means any custom APIs would not yield the same error casing as core ones?

We've made some efforts to enable parity between custom APIs and core APIs - for example offering to apply the same schema and operation IDs. I wonder if we really want to exclude custom APIs from this casing fix?

[Migaroez]

That is correct, but I do not see a way of gracefully handling this within our logic besides relying on an attribute on the (custom) models or using some kind of inheritance.

Or do you want to including something similar to

public class SampleSchemaIdHandler : SchemaIdHandler
{
    public override bool CanHandle(Type type)
        => type.Namespace == "UmbracoDocs.Samples";
}

and then in ManagementApiSystemTextJsonValidationMetadataProvider.CreateValidationMetadata() loop over all Handlers (not what I would call it) to see if any specify that type should be process as if it were a management api model?

[kjac]

Having mulled this over a little bit more, I would actually expect the validation casing to be (forcefully) applied to my API if I've explicitly built on top of the ManagementApiControllerBase - this would ensure consistency in error handling for any Management API consumers?

[Migaroez]

I agree. Sadly you can not reliably get this information from every class/property/context that flows trough that method, at least not according to my experimentation and understanding of the docs.