Consider breaking up ModelValidator

[ajcvickers]

Currently ModelValidator has protected method for each area to validate. These could be instead separate services that can be resolved from D.I. and composed. This could make it easier for non-providers to add custom validation in the same way they can add custom conventions.

Note however that order is important--if we make this change, the current order in which validations happen should not be changed.

Update: the main value here is allowing plugins to do model validation. For example, see change-detecting proxies. See comments below.

[ajcvickers]

Note from triage. Consider a different factoring such that validation is split up by what needs to be verified. For example, for things that need to validate a property, we should iterate over the properties once and call out to each validator in that loop.

[ajcvickers]

Thinking about this again in relation to the PR for change tracking proxies.

Currently there is no way for a non-provider extension to influence model validation because the single IModelValidator service is already overridden by providers. We could implement something similar to IConventionSetPlugin that would allow additional validation to be added. However, the plugin needs to be able to disable or override existing validation, not just add extra validation. Also, the provider may already have overridden the core/relational validation, which may mean that the plugin is overriding/disabling something that it does not know about.

At a high level, it seems that validation should be factored into small discrete blocks. Ideally a provider would then not add additional validation by overriding existing validation. This could be combined with the refactoring mentioned in the note from triage above.

Removing from the backlog to discuss with the team both in terms of the overall plan, the scheduling of the change, and what are immediate guidance is for the change tracking PR.

/cc @AndriySvyryd @orionstudt

[ajcvickers]

Note to implementer: Change detecting proxies (PR #19437) should be updated when this issue is fixed.

[AndriySvyryd]

Note to implementer: Also break up RelationalModelValidator and provide discovered mappings to facilitate validation of relational model. And call ValidateJsonEntities from ValidateSharedTableCompatibility