Improve performance of checking affected conjuncts

[Michiel-s]

Issue As of the fix for #345 all rule conjuncts that are affected when a relation is edited are checked, including those for the UNI and INJ constraints. Given our current database implementation for UNI and INJ relations (as a single column in src or tgt concept table), it is impossible to violate these constraints (except for the situation where a relation is both UNI and INJ, i'll come to that later). It is therefore not necessary to check these UNI and INJ conjuncts.

This issue requests for a 'flag' in the conjuncts.json specification in order for the prototype backend to check or skip the conjunct evaluation. This improves performance of invariant rule checking in a database transaction.

Solution I propose to add an attribute to the conjunct specification in generics/conjuncts.json which sets this flag.

The relation definition rUni :: A * B [UNI] should then results in the following spec:

[{
        "signalRuleNames": [],
        "violationsSQL": "<<the sql query is here>>",
        "invariantRuleNames": [
            "UNI rUni[A*B]"
        ],
        "id": "conj_0",
        "skip" : true
    }]

The same applies to an INJ conjunct.

Action This issue requires work on both sides of the generator API (php backend and Ampersand generator):

• [ ] add 'skip' attribute to conjunct output. set true when conjunct is enforced by database
• [ ] implement skip attribute in php backend. skip conjunct evaluation when set to true.
• [ ] remove temporary function and config for this

Exception to the rule When a relation is both UNI and INJ, the relation is stored in the table of the src concept. The INJ constraint is thereby not guaranteed by the database. To illustrate this: given rUniInj :: A * B [UNI,INJ] the database population could look like:

Therefore, when both UNI and INJ are specified, only one of the two can be skipped depending on the table in which the relation is stored (in this case UNI can be skipped, INJ not)

Future performance improvement The multiplicity constraints UNI, INJ, SUR and TOT can all be implemented as database table column constraints using (NOT) NULL and UNIQUE options. Thereby reducing the amount of queries that must be executed after a transaction even further. Let's create a separate issue for this with very low prio.