Remove broken check for UserGroupPermissionCache consistency

Remove broken check for UserGroupPermissionCache consistency

The purpose of this check is not entirely clear, as it exists since the very
first commit in git. Back then it was not yet broken, it got broken when the
caching system was refactored to reorder parameters, probably in order to
improve the cache hit rates:

When running the `worker`s using the CLI interface, for some reason, the cache
for guests gets rebuilt with the `$parameters` array (and thus by extension the
`groupIDs` value) being equal to `[2, 1]`, whereas everywhere else the
`$parameters` are consistently `[1, 2]`.

Now when rebuilding the data via the CLI, the cache will have the `[2, 1]`
order and when reloading the cache in a regular HTTP session this check will
fail, as `[2, 1] != [1, 2]`, thus completely disregarding the cache contents
and using an empty permissions array instead. This in turn leads to guests not
being able to access anything.

Fix this by removing the safety check:

- It's exceedingly unlikely for two unrelated `$parameters` to collide in the
  cache filename, thus applying incorrect permissions.
- If the CacheBuilder itself is buggy, then all bets are off anyway.