Fix Rich text block validation path

[Migaroez]

Description

The base implementation of the block validator does not take into account that the actual implementation can wrap its content/settings data in another object.
This causes issues with the jsonpath returned in validation messages not matching with the actual property path.

To fix this, the hardcoded mapping was moved into a get only overridable string.

The RTE block validator can now signal the correct path to the base class with an override.

Testing

Ask Niels 😅
Or setup a doctype with a blocklist/grid and an RTE using the same element doctype that has properties with validation that fails on the backend. Create the node add a block to each property => Save and publish => the validate endpoint should return a jsonpath for the invalid properties in the RTE block that starts with $...value.blocks.contentData... instead of $...value.contentData...

[AndyButland]

I've tested this locally and can confirm the API response for the validation path looks as expected.

For the rich text editor, before the PR - i.e. with release/15.3 - the invalid response for a block in an RTE is (which is the same as for a block list):

{
  "type": "Error",
  "title": "Validation failed",
  "status": 400,
  "detail": "One or more properties did not pass validation",
  "operationStatus": "PropertyValidationError",
  "errors": {
    "$.values[0].value.contentData[0].values[0].value": [
      "#validation_invalidEmpty"
    ]
  }
}

With the PR in place we get:

{
  "type": "Error",
  "title": "Validation failed",
  "status": 400,
  "detail": "One or more properties did not pass validation",
  "operationStatus": "PropertyValidationError",
  "errors": {
    "$.values[0].value.blocks.contentData[0].values[0].value": [
      "#validation_invalidEmpty"
    ]
  }
}

[nielslyngsoe]

@Migaroez thanks, works much better now. I approve.