This avoids several sub queries where just one is sufficient.
Before: `(a=b|c=d|e=f)|(g=h|i=j|k=l)|(m=n|o=p)`
After: `(a=b|c=d|e=f|g=h|i=j|k=l|m=n|o=p)`
Whether this has a real advantage needs to be seen, but I
think it helps the query optimizers to better optimize :D
* Auth: Add method `assertColumnRestrictions`
* ObjectSuggestions: Do not suggest protected variables
`assertColumnRestrictions` does not allow to use them
anymore, hence we should not suggest them in searches
as well to not to let the user run into an error by
accepting a suggestion. Though, when fetching values
as well, we still have to obfuscate, otherwise protected
vars won't show up in details anymore.
* Introduce Icinga\Module\Icingadb\Common\Model
Must be used as base for all models, to ensure
column restrictions are asserted on filters.
* Utilize `Icinga\Module\Icingadb\Common\Model` where applicable
Otherwise, redundany_group objects are not visible.
- New filter : Either the host/service is null (the object is a redundancy group) or given restrictions match
Forces the given restriction/filter to be wrapped in a subquery if there is a restriction applied
to `*/services` or `*/hosts` with `hostgroup.name` or `servicegroup.name`. If `hostgroup.name` is
used for services restriction, it is automatically wrapped to a subquery, because service model
has no direct relation to `hostgroup` and it is the same with host model and `servicegroup.name`.
`grantsOnType()` will now perform the permission check it is asked for
on every object that matches the filter. It will then cache all
individual results so that any subsequent call to `grantsOn()` will
hit the cache instead of triggering another query.
