Enh/schema validation attribute values

[MBueschelberger]

closes #828

New functionalities for checking the value and length (if it is string) or range (it is a float/int/bool) of a CUDS-attribute.

Please see the updated unittests as reference for this example:

city.Citizen:
    city.name:
        STRING:
            length: 1+
            cardinality: 1
    city.age:
        INT:
            range: 0+
            cardinality: 1

In the case of a string for an attribute, we can state what should be the length of a city.name. For all other types, we can specify the numerical range.

Here is an example of how to restrict a cuds with respect to a certain value, which is very useful for unittesting:

city.Citizen:
    city.name:
        STRING:
            value: peter
            cardinality: 1
    city.age:
        INT:
            value: 18
            cardinality: 1

Furthermore, the schema validation received an extra keyword-argument called strict_check which - as the name already says - triggers a strict check of the cuds during the validation. This basically means that the test fails when any extra cuds apart the ones listed in the schema-file are encountered while querying the root object.

Please note: This implementation is closely imitating what is supposed to be covered by any standardized markup-language such as SHACL. But due to lack of time in the use case, we could not really focus on integrating these languages into simphony-osp, because the effort for translating the schema file into the required shapes was too high.

[MBueschelberger]

@kysrpex , there seems to be some problem with the sqlite-wrapper in the pipeline. I am not sure if this is related to the native sqlite3-package from python3.

[MBueschelberger]

Why does the pipeline fail again after you merged dev into this branch at commit d3bc34e2b9ae9d5b88c7fa092ba2071f288fc45d? The pipeline for commit 1a42f0f6731014c43b8ebc2b4e81963f19a8cfe2 was successful but not for the following 15a168c3afcde72fd2094e89ce67afc234155aad? This is confusing

[kysrpex]

Why does the pipeline fail again after you merged dev into this branch at commit d3bc34e2b9ae9d5b88c7fa092ba2071f288fc45d? The pipeline for commit 1a42f0f6731014c43b8ebc2b4e81963f19a8cfe2 was successful but not for the following 15a168c3afcde72fd2094e89ce67afc234155aad? This is confusing

Good question honestly, I will try to find out.