Add option to enforce validation based on referenced WoT model

[thjaeckle]

Currently, Ditto's WoT Integration does not ensure/enforce the referenced model.

As the reference implementation, Eclipse Thingweb did also not do that we thought that would be a common practice to move validation to eg producers of messages.

In practice I now see that an enforcement of the model by Ditto would have great benefits and is the best place to add validation.
This would eg ensure that different API consumers always modify a thing only in the intended and modeled way.

That would be especially important if the Ditto managed twin is used in an Event driven system, where changes of the twin state is reacted to by eg issuing a command downlink to an actual device (using "desired properties" approach).

This issue should track:

• new config option to enable wot validation
• implementation and making configurable all of the below:
  • validation of attributes on thing level
  • validation of properties of features
  • validation of desired properties of features (ignoring "required" constraints)
  • validation of thing messages
  • validation of feature messages
  • whether to allow modifying non modeled attributes/properties or to reject them
  • whether to allow sending of non modeled messages (wot actions/events) or to reject them

I expect this to be quite difficult to do, as we have to extract the JsonSchema parts from WoT TM models and apply them.
Both when eg a complete thing is modified and also partially, when eg only a single feature or even property or even part of a property is modified.

[thjaeckle]

I think that we need to validate always what the target state of the complete thing (or feature if only a feature was modifier) would be against the model.

So after enforcement (different permissions should not yield different validation results), but before applying a modify command to the persistence.

We should also monitor how much time validation takes, by adding metrics (spans) to the existing signal processing trace.

It would ne nice to have the validation as separate Java Module so that it could also be used as a library.

[thjaeckle]

Another idea on the enforcement:
Configure a list of auth subjects (also supporting wildcards) for which validation is not done.

I am thinking especially about eg connections where we don't necessarily rely on a user input to validate.
Whereas for api users, eg authenticated via JWT and the http api, it would be important to validate all provided data.